[jira] [Commented] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194782#comment-15194782
]
Dmitry Karachentsev commented on IGNITE-2798:
-
I don't think so, because in regular case this state will be exceptional.
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194752#comment-15194752
]
Valentin Kulichenko commented on IGNITE-2798:
-
Dmitry,
Is it possible not to print out the exception in this case? It's not very good
that we flood the logs with meaningless error.
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2778) implemente support to include jade for jspm
[ https://issues.apache.org/jira/browse/IGNITE-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-2778. Assignee: (was: Alexey Kuznetsov) Merged to staging. > implemente support to include jade for jspm > --- > > Key: IGNITE-2778 > URL: https://issues.apache.org/jira/browse/IGNITE-2778 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriyff > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2789) Fix dropdown placeholder
[ https://issues.apache.org/jira/browse/IGNITE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-2789. Assignee: (was: Alexey Kuznetsov) > Fix dropdown placeholder > > > Key: IGNITE-2789 > URL: https://issues.apache.org/jira/browse/IGNITE-2789 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriyff > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2789) Fix dropdown placeholder
[ https://issues.apache.org/jira/browse/IGNITE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-2789. -- Resolution: Fixed Merged into staging. > Fix dropdown placeholder > > > Key: IGNITE-2789 > URL: https://issues.apache.org/jira/browse/IGNITE-2789 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriyff >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2612) Refactor Caches screen to Angular directives
[ https://issues.apache.org/jira/browse/IGNITE-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-2612. -- Resolution: Fixed Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) Vasiliy, please test on staging and if all is OK submit for test to Pavel. > Refactor Caches screen to Angular directives > > > Key: IGNITE-2612 > URL: https://issues.apache.org/jira/browse/IGNITE-2612 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Vasiliy Sisko > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-846) Add missed computegrid scala examples.
[ https://issues.apache.org/jira/browse/IGNITE-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-846: Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Add missed computegrid scala examples. > -- > > Key: IGNITE-846 > URL: https://issues.apache.org/jira/browse/IGNITE-846 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: sprint-5 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: #_IGNITE-846_Computegrid_examples.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-871) Add missed datastructures scala examples
[ https://issues.apache.org/jira/browse/IGNITE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-871: Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Add missed datastructures scala examples > > > Key: IGNITE-871 > URL: https://issues.apache.org/jira/browse/IGNITE-871 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: sprint-5 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: #_IGNITE-871_Datastructures_examples.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-897) Add missed datagrid scala examples
[ https://issues.apache.org/jira/browse/IGNITE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-897: Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Add missed datagrid scala examples > -- > > Key: IGNITE-897 > URL: https://issues.apache.org/jira/browse/IGNITE-897 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: sprint-5 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: #_IGNITE-897_Datagrid_examples.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-596) Add missed scala examples and remove unnecessary scala examples.
[ https://issues.apache.org/jira/browse/IGNITE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-596. -- Resolution: Fixed Merged with last master, updated examples to actual state. > Add missed scala examples and remove unnecessary scala examples. > - > > Key: IGNITE-596 > URL: https://issues.apache.org/jira/browse/IGNITE-596 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-3 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: #_IGNITE-596_All_examples.patch, > #_IGNITE-596_Other_examples.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2832) CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory
Valentin Kulichenko created IGNITE-2832:
---
Summary: CacheJdbcPojoStoreFactory.dataSource property should be
replaced with Factory
Key: IGNITE-2832
URL: https://issues.apache.org/jira/browse/IGNITE-2832
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Fix For: 1.6
{{CacheJdbcPojoStoreFactory.dataSource}} property seems to be useless and
confusing, because it's transient and therefore data source is lost when
configuration is serialized.
This property should be deprecated and replaced with {{Factory}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2831) Support advertised address for use with EC2 service discovery
[
https://issues.apache.org/jira/browse/IGNITE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194401#comment-15194401
]
Valentin Kulichenko edited comment on IGNITE-2831 at 3/14/16 11:45 PM:
---
{{AddressResolver}} in this case should do exactly what you described - call
the URL and return the public address. This way user will only have to provide
this resolver in the configuration.
Currently user can do this by himself, but this will require coding and
deploying this code on all instances.
was (Author: vkulichenko):
{{AddressResolver}} in this case should do exactly what you described - call
the URL and return the public address. This way user will only have to provide
this resolver in the configuration.
> Support advertised address for use with EC2 service discovery
> -
>
> Key: IGNITE-2831
> URL: https://issues.apache.org/jira/browse/IGNITE-2831
> Project: Ignite
> Issue Type: Improvement
>Reporter: Cory Parent
>Priority: Blocker
>
> Currently it is not possible to connect to an Ignite cluster as a client from
> a non-AWS environment (e.g. local development machine) due to the manner in
> which Ignite registers instance addresses. I propose that the default
> behavior (registering the private IP address) should remain, however, the
> ability to mitigate this issue should be provided via a method to use an
> advertised address instead. Such a solution is provided by Kafka
> configuration to resolve this very issue. This would allow us to override the
> private IP address with a public or Elastic IP, thus allowing connection from
> non-AWS environments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2831) Support advertised address for use with EC2 service discovery
[
https://issues.apache.org/jira/browse/IGNITE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194401#comment-15194401
]
Valentin Kulichenko commented on IGNITE-2831:
-
{{AddressResolver}} in this case should do exactly what you described - call
the URL and return the public address. This way user will only have to provide
this resolver in the configuration.
> Support advertised address for use with EC2 service discovery
> -
>
> Key: IGNITE-2831
> URL: https://issues.apache.org/jira/browse/IGNITE-2831
> Project: Ignite
> Issue Type: Improvement
>Reporter: Cory Parent
>Priority: Blocker
>
> Currently it is not possible to connect to an Ignite cluster as a client from
> a non-AWS environment (e.g. local development machine) due to the manner in
> which Ignite registers instance addresses. I propose that the default
> behavior (registering the private IP address) should remain, however, the
> ability to mitigate this issue should be provided via a method to use an
> advertised address instead. Such a solution is provided by Kafka
> configuration to resolve this very issue. This would allow us to override the
> private IP address with a public or Elastic IP, thus allowing connection from
> non-AWS environments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2829) Unable to cache two beans with same class name but different package
[
https://issues.apache.org/jira/browse/IGNITE-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194385#comment-15194385
]
Valentin Kulichenko commented on IGNITE-2829:
-
Kranthi,
I believe this is already fixed in master. Can you build from there and check?
> Unable to cache two beans with same class name but different package
>
>
> Key: IGNITE-2829
> URL: https://issues.apache.org/jira/browse/IGNITE-2829
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
> Environment: Tested on Windows and linux OS
>Reporter: Kranthi Kiran
> Fix For: 1.6
>
>
> Hi,
> We are trying to cache two beans with same class name but different package
> and we are getting error something like below. Can you please help in this
> regards. After little debugging I found it is because of
> "org.apache.ignite.internal.binary.BinaryContext" line # 988, where only
> simple-class name is considered instead of full-qualified-class name.
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Duplicate ID [id=-1146372286,
> oldCls=com.yodlee.ignite.test.sub1.TestBean,
> newCls=com.yodlee.ignite.test.sub2.TestBean
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1618)
> ...
> Caused by: class org.apache.ignite.IgniteCheckedException: Duplicate ID
> [id=-1146372286, oldCls=com.yodlee.ignite.test.sub1.TestBean,
> newCls=com.yodlee.ignite.test.sub2.TestBean
> at
> org.apache.ignite.internal.MarshallerContextAdapter.registerClass(MarshallerContextAdapter.java:163)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:562)
> ...
> .
> Below is the test program I have written to simulate the problem
> Main Program
> ===
> public static void main(String[] args)
> {
> IgniteConfiguration config = new IgniteConfiguration();
> config.setClientMode(false);
> config.setPeerClassLoadingEnabled(false);
>
> Ignite ignite = Ignition.start(config);
> System.out.println("Server started...");
>
> CacheConfiguration cacheConfig = new
> CacheConfiguration();
> cacheConfig.setName("test");
> IgniteCache testCache =
> ignite.getOrCreateCache(cacheConfig);
> testCache.put("bean1", new TestBean("bean1"));
> testCache.put("bean2", new
> com.yodlee.ignite.test.sub2.TestBean("bean2"));
>
> System.out.println("Completed");
> }
> com.yodlee.ignite.test.sub1.TestBean
>
> package com.yodlee.ignite.test.sub1;
> public class TestBean
> {
> private String name;
>
> public TestBean()
> {}
>
> public TestBean(String name)
> {
> this.name = name;
> }
> public String getName()
> {
> return name;
> }
> public void setName(String name)
> {
> this.name = name;
> }
> }
> com.yodlee.ignite.test.sub2.TestBean
> =
> package com.yodlee.ignite.test.sub2;
> public class TestBean
> {
> private String name;
>
> public TestBean()
> {}
> public TestBean(String name)
> {
> this.name = name;
> }
> public String getName()
> {
> return name;
> }
> public void setName(String name)
> {
> this.name = name;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2831) Support advertised address for use with EC2 service discovery
[ https://issues.apache.org/jira/browse/IGNITE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194013#comment-15194013 ] Cory Parent commented on IGNITE-2831: - I agree with this solution as it doesn't require any additional information and would remain platform agnostic. A simple call to `http://169.254.169.254/latest/meta-data/public-ipv4` should solve the issue. In lieu of out of the box support for the time being, could you provide any guidance on the interim solution? Perhaps an example of implementing the `AddressResolver`? > Support advertised address for use with EC2 service discovery > - > > Key: IGNITE-2831 > URL: https://issues.apache.org/jira/browse/IGNITE-2831 > Project: Ignite > Issue Type: Improvement >Reporter: Cory Parent >Priority: Blocker > > Currently it is not possible to connect to an Ignite cluster as a client from > a non-AWS environment (e.g. local development machine) due to the manner in > which Ignite registers instance addresses. I propose that the default > behavior (registering the private IP address) should remain, however, the > ability to mitigate this issue should be provided via a method to use an > advertised address instead. Such a solution is provided by Kafka > configuration to resolve this very issue. This would allow us to override the > private IP address with a public or Elastic IP, thus allowing connection from > non-AWS environments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2831) Support advertised address for use with EC2 service discovery
[
https://issues.apache.org/jira/browse/IGNITE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193906#comment-15193906
]
Valentin Kulichenko commented on IGNITE-2831:
-
This can be achieved by implementing {{AddressResolver}} interface. I think we
should provide implementations for clouds out of the box. E.g., for EC2 this
can be done using metadata URLs:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html
> Support advertised address for use with EC2 service discovery
> -
>
> Key: IGNITE-2831
> URL: https://issues.apache.org/jira/browse/IGNITE-2831
> Project: Ignite
> Issue Type: Improvement
>Reporter: Cory Parent
>Priority: Blocker
>
> Currently it is not possible to connect to an Ignite cluster as a client from
> a non-AWS environment (e.g. local development machine) due to the manner in
> which Ignite registers instance addresses. I propose that the default
> behavior (registering the private IP address) should remain, however, the
> ability to mitigate this issue should be provided via a method to use an
> advertised address instead. Such a solution is provided by Kafka
> configuration to resolve this very issue. This would allow us to override the
> private IP address with a public or Elastic IP, thus allowing connection from
> non-AWS environments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2795) Cache query cursor do not create value copy
[ https://issues.apache.org/jira/browse/IGNITE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko reassigned IGNITE-2795: --- Assignee: Valentin Kulichenko > Cache query cursor do not create value copy > --- > > Key: IGNITE-2795 > URL: https://issues.apache.org/jira/browse/IGNITE-2795 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > Attachments: QueryTest.java > > > If entries returned from SQL query are modified, these changes are reflected > in the cache. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193521#comment-15193521 ] Saikat Maitra commented on IGNITE-813: -- [~roman_s] Roman, I have implemented similar to Flink streaming connectors https://ci.apache.org/projects/flink/flink-docs-master/apis/streaming/connectors/index.html but instead of using Ignite FileSystem I am using IgniteQueue as a sink for storing the computation results. The code changes is similar to StormStreamer but I extended RichSinkFunction to collect the computation data and persist in IgniteQueue. Regards Saikat > Apache Flink Integration > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193514#comment-15193514 ] Anton Vinogradov commented on IGNITE-813: - Saikat, Please don't forget to refactor code according to https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines Thanks! > Apache Flink Integration > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2831) Support advertised address for use with EC2 service discovery
Cory Parent created IGNITE-2831: --- Summary: Support advertised address for use with EC2 service discovery Key: IGNITE-2831 URL: https://issues.apache.org/jira/browse/IGNITE-2831 Project: Ignite Issue Type: Improvement Reporter: Cory Parent Priority: Blocker Currently it is not possible to connect to an Ignite cluster as a client from a non-AWS environment (e.g. local development machine) due to the manner in which Ignite registers instance addresses. I propose that the default behavior (registering the private IP address) should remain, however, the ability to mitigate this issue should be provided via a method to use an advertised address instead. Such a solution is provided by Kafka configuration to resolve this very issue. This would allow us to override the private IP address with a public or Elastic IP, thus allowing connection from non-AWS environments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2797) Prepare and finish future never time out
[ https://issues.apache.org/jira/browse/IGNITE-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193455#comment-15193455 ] Semen Boikov commented on IGNITE-2797: -- As first step added more tests for tx with timeout when 'lock' step fails because of timeout (CacheTxLockTimeoutTest). One issue found: it seems that GridNearTxFinishRequest for timed out tx can be processed before GridNearLockRequest, in this case lock is not released (see 'testDelayNearLockRequest'). > Prepare and finish future never time out > > > Key: IGNITE-2797 > URL: https://issues.apache.org/jira/browse/IGNITE-2797 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Priority: Blocker > Labels: community, customer, important > Fix For: 1.6 > > > Even if transaction timeout is configured, transaction will not timeout if > it's already in prepare state. It will be shown in log as pending transaction > and can cause the whole cluster hang. > We need to add a mechanism that will properly timeout prepare and (if > possible) finish futures. > Also we can create an event that will be fired if there is a transaction > pending for a long time, showing which nodes we are waiting responses from. > This will allow user to recover by stopping only these nodes instead of > restarting the whole cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2798.
---
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2830) IGFS: Added multi-node tests for IgfsAbstractSelfTest.
Vladimir Ozerov created IGNITE-2830: --- Summary: IGFS: Added multi-node tests for IgfsAbstractSelfTest. Key: IGNITE-2830 URL: https://issues.apache.org/jira/browse/IGNITE-2830 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Ivan Veselovsky Fix For: 1.6 Currently our base tests run in a single-node environment. This is not very valid use case. Let's run it multi-node deployment. This relates only to primary file system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2829) Unable to cache two beans with same class name but different package
[
https://issues.apache.org/jira/browse/IGNITE-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kranthi Kiran updated IGNITE-2829:
--
Description:
Hi,
We are trying to cache two beans with same class name but different package and
we are getting error something like below. Can you please help in this regards.
After little debugging I found it is because of
"org.apache.ignite.internal.binary.BinaryContext" line # 988, where only
simple-class name is considered instead of full-qualified-class name.
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Duplicate ID [id=-1146372286,
oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1618)
...
Caused by: class org.apache.ignite.IgniteCheckedException: Duplicate ID
[id=-1146372286, oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.MarshallerContextAdapter.registerClass(MarshallerContextAdapter.java:163)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:562)
...
.
Below is the test program I have written to simulate the problem
Main Program
===
public static void main(String[] args)
{
IgniteConfiguration config = new IgniteConfiguration();
config.setClientMode(false);
config.setPeerClassLoadingEnabled(false);
Ignite ignite = Ignition.start(config);
System.out.println("Server started...");
CacheConfiguration cacheConfig = new
CacheConfiguration();
cacheConfig.setName("test");
IgniteCache testCache =
ignite.getOrCreateCache(cacheConfig);
testCache.put("bean1", new TestBean("bean1"));
testCache.put("bean2", new
com.yodlee.ignite.test.sub2.TestBean("bean2"));
System.out.println("Completed");
}
com.yodlee.ignite.test.sub1.TestBean
package com.yodlee.ignite.test.sub1;
public class TestBean
{
private String name;
public TestBean()
{}
public TestBean(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
com.yodlee.ignite.test.sub2.TestBean
=
package com.yodlee.ignite.test.sub2;
public class TestBean
{
private String name;
public TestBean()
{}
public TestBean(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
was:
Hi,
We are trying to cache two beans with same class name but different package and
we are getting error something like below. Can you please help in this regards
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Duplicate ID [id=-1146372286,
oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1618)
...
Caused by: class org.apache.ignite.IgniteCheckedException: Duplicate ID
[id=-1146372286, oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.MarshallerContextAdapter.registerClass(MarshallerContextAdapter.java:163)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:562)
...
.
Below is the test program I have written to simulate the problem
Main Program
===
public static void main(String[] args)
{
IgniteConfiguration config = new IgniteConfiguration();
config.setClientMode(false);
config.setPeerClassLoadingEnabled(false);
Ignite ignite = Ignition.start(config);
System.out.println("Server started...");
CacheConfiguration cacheConfig = new
CacheConfiguration();
cacheConfig.setName("test");
IgniteCache testCache =
ignite.getOrCreateCache(cacheConfig);
testCache.put("bean1", new TestBean("bean1"));
testCache.put("bean2", new
com.yod
[jira] [Resolved] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev resolved IGNITE-2798.
-
Resolution: Not A Problem
Assignee: Vladimir Ozerov (was: Dmitry Karachentsev)
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193324#comment-15193324
]
Dmitry Karachentsev commented on IGNITE-2798:
-
It's not an issue. Looks like brand new node in topology receives close
transaction message, but at that moment knows nothing about it.
> 'Transaction has already been completed' in restart tests
> -
>
> Key: IGNITE-2798
> URL: https://issues.apache.org/jira/browse/IGNITE-2798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 1.6
>
>
> When running transaction tests with node restarts (e.g.
> {{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
> exceptions like below. Need to check if it's an issue or not.
> {noformat}
> [18:03:18,760][WARN
> ][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
> Received finish request for completed transaction (the message may be too
> late and transaction could have been DGCed by now) [commit=false,
> xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
> globalTime=1457661798754, order=1457662644887]]
> [18:03:18] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Transaction has
> been already completed.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2829) Unable to cache two beans with same class name but different package
Kranthi Kiran created IGNITE-2829:
-
Summary: Unable to cache two beans with same class name but
different package
Key: IGNITE-2829
URL: https://issues.apache.org/jira/browse/IGNITE-2829
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5.0.final
Environment: Tested on Windows and linux OS
Reporter: Kranthi Kiran
Fix For: 1.6
Hi,
We are trying to cache two beans with same class name but different package and
we are getting error something like below. Can you please help in this regards
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Duplicate ID [id=-1146372286,
oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1618)
...
Caused by: class org.apache.ignite.IgniteCheckedException: Duplicate ID
[id=-1146372286, oldCls=com.yodlee.ignite.test.sub1.TestBean,
newCls=com.yodlee.ignite.test.sub2.TestBean
at
org.apache.ignite.internal.MarshallerContextAdapter.registerClass(MarshallerContextAdapter.java:163)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:562)
...
.
Below is the test program I have written to simulate the problem
Main Program
===
public static void main(String[] args)
{
IgniteConfiguration config = new IgniteConfiguration();
config.setClientMode(false);
config.setPeerClassLoadingEnabled(false);
Ignite ignite = Ignition.start(config);
System.out.println("Server started...");
CacheConfiguration cacheConfig = new
CacheConfiguration();
cacheConfig.setName("test");
IgniteCache testCache =
ignite.getOrCreateCache(cacheConfig);
testCache.put("bean1", new TestBean("bean1"));
testCache.put("bean2", new
com.yodlee.ignite.test.sub2.TestBean("bean2"));
System.out.println("Completed");
}
com.yodlee.ignite.test.sub1.TestBean
package com.yodlee.ignite.test.sub1;
public class TestBean
{
private String name;
public TestBean()
{}
public TestBean(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
com.yodlee.ignite.test.sub2.TestBean
=
package com.yodlee.ignite.test.sub2;
public class TestBean
{
private String name;
public TestBean()
{}
public TestBean(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure
[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193257#comment-15193257
]
Yakov Zhdanov commented on IGNITE-642:
--
Vlad,
Thanks for the response!
I have pulled out the most recent version of the PR and now I have minor
conflict with master in {{DataStructuresProcessor}} and I still have
compilation errors related to final variables declaration (please make sure
your code is buildable with jdk7).
Can you please resolve these issues and submit issue for review one more time?
I also see the following issues
# org.apache.ignite.internal.processors.datastructures.GridCacheLockEx#stop -
all callback methods in this class have {{onXXX()}} prefix. I think this should
be {{onStop()}} as well.
# As I see not all methods are covered with at least minimal unit tests, e.g.
org.apache.ignite.IgniteLock#getWaitQueueLength
# I don't think we should have methods like toString() in interfaces. Also
methods that do not add exceptions or documentation or do not alter return type
from super interface should not be declared within Ignite interfaces (what
for?).
# I would like you to add throws declaration to {{lock()}} method and other
methods which may involve distributed operation, since I am pretty sure that
any operation of the kind may throw exception. Please also add tests for this.
# Please add the following scenario. Start server node, then client node, get
lock from client node, acquire lock then unlock, then stop server node and try
to acquire lock. I assume exception should be thrown.
Thanks!
> Implement IgniteReentrantLock data structure
>
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Affects Versions: 1.6
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
> Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2828) IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update.
[ https://issues.apache.org/jira/browse/IGNITE-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2828. --- > IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update. > - > > Key: IGNITE-2828 > URL: https://issues.apache.org/jira/browse/IGNITE-2828 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Currently we use cache "put" and this is less than optimal. Light-weight > entry processor should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2828) IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update.
[ https://issues.apache.org/jira/browse/IGNITE-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2828. - Resolution: Fixed > IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update. > - > > Key: IGNITE-2828 > URL: https://issues.apache.org/jira/browse/IGNITE-2828 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Currently we use cache "put" and this is less than optimal. Light-weight > entry processor should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2763) GridDhtPartitionDemander fails with assertion on partition move
[
https://issues.apache.org/jira/browse/IGNITE-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov closed IGNITE-2763.
> GridDhtPartitionDemander fails with assertion on partition move
> ---
>
> Key: IGNITE-2763
> URL: https://issues.apache.org/jira/browse/IGNITE-2763
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Dmitry Karachentsev
>Assignee: Anton Vinogradov
> Fix For: 1.6
>
>
> When starts single node and is filled with cache items, then are started
> three new nodes GridDhtPartitionDemander fails with assertion error.
> {noformat}
> java.lang.AssertionError: Partition already done [cache=cache_name,
> fromNode=1073a1d0-5139-44d3-9dee-399637bfd001, part=0, left=[2, 259, 771, 5,
> 6, 518, 774, 263, 775, 780, 271, 275, 540, 797, 30, 32, 802, 547, 807, 810,
> 556, 45, 301, 813, 302, 305, 561, 55, 312, 57, 59, 575, 324, 327, 331, 336,
> 594, 597, 598, 88, 859, 605, 606, 353, 867, 357, 871, 873, 363, 875, 371,
> 631, 887, 383, 640, 896, 898, 899, 644, 900, 646, 903, 905, 652, 908, 653,
> 912, 660, 662, 919, 153, 419, 422, 934, 172, 173, 429, 941, 176, 177, 180,
> 694, 953, 955, 445, 957, 959, 448, 451, 707, 199, 201, 972, 205, 718, 974,
> 207, 208, 721, 725, 471, 728, 985, 986, 475, 987, 477, 478, 225, 230, 233,
> 747, 237, 750, 497, 756, 503, 505, 1018, 1019, 764, 510, 1022]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:978)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Pull request with test that reproduces problem
> https://github.com/apache/ignite/pull/538
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2763) GridDhtPartitionDemander fails with assertion on partition move
[
https://issues.apache.org/jira/browse/IGNITE-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-2763.
--
Resolution: Fixed
merged to master
> GridDhtPartitionDemander fails with assertion on partition move
> ---
>
> Key: IGNITE-2763
> URL: https://issues.apache.org/jira/browse/IGNITE-2763
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Dmitry Karachentsev
>Assignee: Anton Vinogradov
> Fix For: 1.6
>
>
> When starts single node and is filled with cache items, then are started
> three new nodes GridDhtPartitionDemander fails with assertion error.
> {noformat}
> java.lang.AssertionError: Partition already done [cache=cache_name,
> fromNode=1073a1d0-5139-44d3-9dee-399637bfd001, part=0, left=[2, 259, 771, 5,
> 6, 518, 774, 263, 775, 780, 271, 275, 540, 797, 30, 32, 802, 547, 807, 810,
> 556, 45, 301, 813, 302, 305, 561, 55, 312, 57, 59, 575, 324, 327, 331, 336,
> 594, 597, 598, 88, 859, 605, 606, 353, 867, 357, 871, 873, 363, 875, 371,
> 631, 887, 383, 640, 896, 898, 899, 644, 900, 646, 903, 905, 652, 908, 653,
> 912, 660, 662, 919, 153, 419, 422, 934, 172, 173, 429, 941, 176, 177, 180,
> 694, 953, 955, 445, 957, 959, 448, 451, 707, 199, 201, 972, 205, 718, 974,
> 207, 208, 721, 725, 471, 728, 985, 986, 475, 987, 477, 478, 225, 230, 233,
> 747, 237, 750, 497, 756, 503, 505, 1018, 1019, 764, 510, 1022]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:978)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Pull request with test that reproduces problem
> https://github.com/apache/ignite/pull/538
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2404) TcpDiscoverySpi.setLocalPortRange set 0 doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193099#comment-15193099 ] Denis Magda commented on IGNITE-2404: - Hi, Thanks for the contribution. I'll review your changes in the nearest couple of days and will answer on other questions. > TcpDiscoverySpi.setLocalPortRange set 0 doesn't work > - > > Key: IGNITE-2404 > URL: https://issues.apache.org/jira/browse/IGNITE-2404 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Ryan Zhao > Labels: community, newbie > > Local port range set to 0 presently doesn't work at least for > TcpCommunicationSpi and TcpDiscoverySpi. However SPIs support it. > In my understanding the condition has to changed to the following one (from < > to <=). > x = port; x <= port + range -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2817) IGFS: "update*" operations in IgfsMetaManager should not use "put" operations.
[
https://issues.apache.org/jira/browse/IGNITE-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193100#comment-15193100
]
Vladimir Ozerov commented on IGNITE-2817:
-
Problem methods:
1) updateInfo
2) updatePropertiesNonTx
> IGFS: "update*" operations in IgfsMetaManager should not use "put" operations.
> --
>
> Key: IGNITE-2817
> URL: https://issues.apache.org/jira/browse/IGNITE-2817
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> There are several "update*" methods in {{IgfsMetaManager}} which perform some
> minor operations like properties or access time updates. And they use "put"
> or "putIfAbsent" for this, which is less than optimal.
> *Solution*
> Use entry processors instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2828) IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update.
Vladimir Ozerov created IGNITE-2828: --- Summary: IGFS: IgfsMetaManager.updateTimes() must use entry processor for file update. Key: IGNITE-2828 URL: https://issues.apache.org/jira/browse/IGNITE-2828 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 Currently we use cache "put" and this is less than optimal. Light-weight entry processor should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2827) .NET: Write XmlSerializer types as binary
Pavel Tupitsyn created IGNITE-2827: -- Summary: .NET: Write XmlSerializer types as binary Key: IGNITE-2827 URL: https://issues.apache.org/jira/browse/IGNITE-2827 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Types intended to be serialized with XmlSerializer can be identified by [XmlRoot] attribute, or one of the [XmlElement], [XmlAttribute], etc attributes on type members. We should write such types using Ignite binary format, and respect attributes where applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2404) TcpDiscoverySpi.setLocalPortRange set 0 doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193085#comment-15193085 ] Ryan Zhao commented on IGNITE-2404: --- Hi, in the implementation of the change presented above, I have found that many component in Ignite have a portRange parameter, such as IgniteConfiguration#getTimeServerPortRange and ConnectorConfiguration#getPortRange. And in these scenarios portRange equals 0 is considered to be a mistake. So, I think we should keep this consistency, and make the docs more clear. Any thoughts? > TcpDiscoverySpi.setLocalPortRange set 0 doesn't work > - > > Key: IGNITE-2404 > URL: https://issues.apache.org/jira/browse/IGNITE-2404 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Ryan Zhao > Labels: community, newbie > > Local port range set to 0 presently doesn't work at least for > TcpCommunicationSpi and TcpDiscoverySpi. However SPIs support it. > In my understanding the condition has to changed to the following one (from < > to <=). > x = port; x <= port + range -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2826) .NET: Write DataContract types as binary
[ https://issues.apache.org/jira/browse/IGNITE-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2826: --- Summary: .NET: Write DataContract types as binary (was: .NET: Write DataContract classes as binary) > .NET: Write DataContract types as binary > > > Key: IGNITE-2826 > URL: https://issues.apache.org/jira/browse/IGNITE-2826 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn > Fix For: 1.6 > > > Types marked with [DataContract] attribute should be written in binary > format, respecting [DataMember] and other related attributes, so that > existing user types can be used in Ignite without any changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2826) .NET: Write DataContract classes as binary
Pavel Tupitsyn created IGNITE-2826: -- Summary: .NET: Write DataContract classes as binary Key: IGNITE-2826 URL: https://issues.apache.org/jira/browse/IGNITE-2826 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Types marked with [DataContract] attribute should be written in binary format, respecting [DataMember] and other related attributes, so that existing user types can be used in Ignite without any changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2825) .NET: Write Serializable as binary
Pavel Tupitsyn created IGNITE-2825: -- Summary: .NET: Write Serializable as binary Key: IGNITE-2825 URL: https://issues.apache.org/jira/browse/IGNITE-2825 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Write [Serializable] classes in Ignite binary format. Employ the same logic as .NET does with NonSerializedAttribute and ISerializable interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2824) IGFS: File close should require only one meta transaction.
Vladimir Ozerov created IGNITE-2824:
---
Summary: IGFS: File close should require only one meta transaction.
Key: IGNITE-2824
URL: https://issues.apache.org/jira/browse/IGNITE-2824
Project: Ignite
Issue Type: Bug
Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Fix For: 1.6
*Problem*
Have a look at {{IgfsOutputStreamImpl.onClose(boolean)}} method. It performs
two sequential calls:
1) meta.unlock();
2) meta.updateParentListingAsync().
It spans two transactions and hence two 2PC routines, leading to less than
optimal performance.
*Solution*
Update both file and it's parent in a single transaction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible.
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193048#comment-15193048 ] Pavel Tupitsyn commented on IGNITE-2703: The following should be done: * In this ticket, enable dynamic registration for all non-[Serializable] types. Nothing changes for Serializable types. * In separate tickets, we should respect [Serializable], ISerializable, [DataContract] and XmlSerializer attributes, but use our own binary serialization. > .NET: Dynamically registered classes must use binary serialization if > possible. > --- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.6 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2814) IGFS: Optimize file meta update operations using entry processors.
[
https://issues.apache.org/jira/browse/IGNITE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2814.
---
> IGFS: Optimize file meta update operations using entry processors.
> --
>
> Key: IGNITE-2814
> URL: https://issues.apache.org/jira/browse/IGNITE-2814
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> There are 3 operation types performed on files during write:
> 1) lock
> 2) unlock
> 3) length update
> Some of there operations perform put/replace on cache to update meta. This is
> less than efficient because we have to pass the file {{IgfsFileInfo}} which
> is pretty heavy.
> *Solution*
> We must ensure that all these operations use light-weight entry processors
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2823) CPP: Split libcommon in two libraries to get rid of libjvm dependency.
[ https://issues.apache.org/jira/browse/IGNITE-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-2823: Assignee: Igor Sapego Affects Version/s: 1.5.0.final Description: Currently libcommon depends on the libjvm but provides other utilities and macros which other libraries depend upon. So we need to link libcommon always when we use utils even if we don't use libjvm (e.g. in ODBC driver). Component/s: (was: important) platforms odbc > CPP: Split libcommon in two libraries to get rid of libjvm dependency. > -- > > Key: IGNITE-2823 > URL: https://issues.apache.org/jira/browse/IGNITE-2823 > Project: Ignite > Issue Type: Sub-task > Components: odbc, platforms >Affects Versions: 1.5.0.final >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.6 > > > Currently libcommon depends on the libjvm but provides other utilities and > macros which other libraries depend upon. So we need to link libcommon always > when we use utils even if we don't use libjvm (e.g. in ODBC driver). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2814) IGFS: Optimize file meta update operations using entry processors.
[
https://issues.apache.org/jira/browse/IGNITE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2814.
-
Resolution: Fixed
> IGFS: Optimize file meta update operations using entry processors.
> --
>
> Key: IGNITE-2814
> URL: https://issues.apache.org/jira/browse/IGNITE-2814
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> There are 3 operation types performed on files during write:
> 1) lock
> 2) unlock
> 3) length update
> Some of there operations perform put/replace on cache to update meta. This is
> less than efficient because we have to pass the file {{IgfsFileInfo}} which
> is pretty heavy.
> *Solution*
> We must ensure that all these operations use light-weight entry processors
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2823) CPP: Split libcommon in two libraries to get rid of libjvm dependency.
Igor Sapego created IGNITE-2823: --- Summary: CPP: Split libcommon in two libraries to get rid of libjvm dependency. Key: IGNITE-2823 URL: https://issues.apache.org/jira/browse/IGNITE-2823 Project: Ignite Issue Type: Sub-task Components: important Reporter: Igor Sapego -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2814) IGFS: Optimize file meta update operations using entry processors.
[
https://issues.apache.org/jira/browse/IGNITE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-2814:
---
Assignee: Vladimir Ozerov
> IGFS: Optimize file meta update operations using entry processors.
> --
>
> Key: IGNITE-2814
> URL: https://issues.apache.org/jira/browse/IGNITE-2814
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> There are 3 operation types performed on files during write:
> 1) lock
> 2) unlock
> 3) length update
> Some of there operations perform put/replace on cache to update meta. This is
> less than efficient because we have to pass the file {{IgfsFileInfo}} which
> is pretty heavy.
> *Solution*
> We must ensure that all these operations use light-weight entry processors
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2817) IGFS: "update*" operations in IgfsMetaManager should not use "put" operations.
[
https://issues.apache.org/jira/browse/IGNITE-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2817:
Summary: IGFS: "update*" operations in IgfsMetaManager should not use "put"
operations. (was: IGFS: "update*" oeprations in IgfsMetaManager should not use
"put" operations.)
> IGFS: "update*" operations in IgfsMetaManager should not use "put" operations.
> --
>
> Key: IGNITE-2817
> URL: https://issues.apache.org/jira/browse/IGNITE-2817
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> There are several "update*" methods in {{IgfsMetaManager}} which perform some
> minor operations like properties or access time updates. And they use "put"
> or "putIfAbsent" for this, which is less than optimal.
> *Solution*
> Use entry processors instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2810) IGFS: Stripe TRASH directory.
[
https://issues.apache.org/jira/browse/IGNITE-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2810.
---
> IGFS: Stripe TRASH directory.
> -
>
> Key: IGNITE-2810
> URL: https://issues.apache.org/jira/browse/IGNITE-2810
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> Currently remove operation on IGFS performs soft-delete which essentially
> moves a file/dir to a special hidden "TRASH" directory. Later on, special
> worker inspects this directory and finally removes actual meta and data
> entities.
> As *move* operation requires lock on parent directory, massive removes will
> lead to high contention on TRASH key, yielding poor performance due to no
> parallelization.
> *Solution*
> Let's stripe trash directory. That is, we will create several (e.g. 16) trash
> directories. When entity is to be removed, we will pick random trash and move
> entitty there.
> Delete worker will have to inspect all these directories.
> Note that each node will have to know maximum numbers of trash directories,
> so it knows how to list it with little or no coordination with other nodes.
> To achieve this we can expose "trashCount" property to
> {{FileSystemConfiguration}}. Normally user will not change it. Each node will
> set up a discovery listener which will track new nodes and will know maximum
> amount of trashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2810) IGFS: Stripe TRASH directory.
[
https://issues.apache.org/jira/browse/IGNITE-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2810.
-
Resolution: Fixed
> IGFS: Stripe TRASH directory.
> -
>
> Key: IGNITE-2810
> URL: https://issues.apache.org/jira/browse/IGNITE-2810
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> Currently remove operation on IGFS performs soft-delete which essentially
> moves a file/dir to a special hidden "TRASH" directory. Later on, special
> worker inspects this directory and finally removes actual meta and data
> entities.
> As *move* operation requires lock on parent directory, massive removes will
> lead to high contention on TRASH key, yielding poor performance due to no
> parallelization.
> *Solution*
> Let's stripe trash directory. That is, we will create several (e.g. 16) trash
> directories. When entity is to be removed, we will pick random trash and move
> entitty there.
> Delete worker will have to inspect all these directories.
> Note that each node will have to know maximum numbers of trash directories,
> so it knows how to list it with little or no coordination with other nodes.
> To achieve this we can expose "trashCount" property to
> {{FileSystemConfiguration}}. Normally user will not change it. Each node will
> set up a discovery listener which will track new nodes and will know maximum
> amount of trashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2812) IGFS: Some operations on DUAL file system could be passed directly to secondary file system.
[ https://issues.apache.org/jira/browse/IGNITE-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky updated IGNITE-2812: Summary: IGFS: Some operations on DUAL file system could be passed directly to secondary file system. (was: IGFS: Some operations on DUAL file system could be passed directly to secondary fiel system.) > IGFS: Some operations on DUAL file system could be passed directly to > secondary file system. > > > Key: IGNITE-2812 > URL: https://issues.apache.org/jira/browse/IGNITE-2812 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov > Fix For: 1.7 > > > *Problem* > When working in DUAL mode, some operations delegate to secondary file system > even if all necessary information is already in IGFS. Example: "list paths" > operation. It has to consult to secondary file system because we are not sure > that all existing entries exists in meta cache. As such, we always delegate > to secondary file system. > *Proposed solution* > Probably we can route such operations directly to seconday FS without > involving IGFS. This will save us several network trips. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192896#comment-15192896
]
ASF GitHub Bot commented on IGNITE-2765:
Github user avinogradovgg closed the pull request at:
https://github.com/apache/ignite/pull/543
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov closed IGNITE-2765.
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192890#comment-15192890
]
Anton Vinogradov edited comment on IGNITE-2765 at 3/14/16 8:16 AM:
---
Val, I've fixed code according to your comments and merged to master
was (Author: avinogradov):
merged to master
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-2765.
--
Resolution: Fixed
merged to master
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2810) IGFS: Stripe TRASH directory.
[
https://issues.apache.org/jira/browse/IGNITE-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-2810:
---
Assignee: Vladimir Ozerov
> IGFS: Stripe TRASH directory.
> -
>
> Key: IGNITE-2810
> URL: https://issues.apache.org/jira/browse/IGNITE-2810
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> Currently remove operation on IGFS performs soft-delete which essentially
> moves a file/dir to a special hidden "TRASH" directory. Later on, special
> worker inspects this directory and finally removes actual meta and data
> entities.
> As *move* operation requires lock on parent directory, massive removes will
> lead to high contention on TRASH key, yielding poor performance due to no
> parallelization.
> *Solution*
> Let's stripe trash directory. That is, we will create several (e.g. 16) trash
> directories. When entity is to be removed, we will pick random trash and move
> entitty there.
> Delete worker will have to inspect all these directories.
> Note that each node will have to know maximum numbers of trash directories,
> so it knows how to list it with little or no coordination with other nodes.
> To achieve this we can expose "trashCount" property to
> {{FileSystemConfiguration}}. Normally user will not change it. Each node will
> set up a discovery listener which will track new nodes and will know maximum
> amount of trashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2816) IGFS: IgfsMetaManager should not use "put" to update parent listing.
[ https://issues.apache.org/jira/browse/IGNITE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2816: Summary: IGFS: IgfsMetaManager should not use "put" to update parent listing. (was: IGFS: IgfsMetaManaget should not use "put" to update parent listing.) > IGFS: IgfsMetaManager should not use "put" to update parent listing. > > > Key: IGNITE-2816 > URL: https://issues.apache.org/jira/browse/IGNITE-2816 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > Lightweight entry processor must be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2819) IGFS: Aggressively cache secondary file system metadata to minimize amount of direct FS calls.
[ https://issues.apache.org/jira/browse/IGNITE-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2819: Summary: IGFS: Aggressively cache secondary file system metadata to minimize amount of direct FS calls. (was: IGFS: Aggressively cache secondayr file system metadata to minimize amount of direct FS calls.) > IGFS: Aggressively cache secondary file system metadata to minimize amount of > direct FS calls. > -- > > Key: IGNITE-2819 > URL: https://issues.apache.org/jira/browse/IGNITE-2819 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > We call secondary file system inside TXes too often to get some metadata. > Instead, when we access any file/dir in DUAL mode for the first time, we > should cache all available metadata from the secondary file system, so that > subsequent calls do not require it any more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2781) IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
[
https://issues.apache.org/jira/browse/IGNITE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2781.
-
Resolution: Fixed
> IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
>
>
> Key: IGNITE-2781
> URL: https://issues.apache.org/jira/browse/IGNITE-2781
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> By default these flags are set to "true" meaning that we will copy values on
> each access.
> We need to set them to {{false}} automatically on node startup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2819) IGFS: Aggressively cache secondayr file system metadata to minimize amount of direct FS calls.
[ https://issues.apache.org/jira/browse/IGNITE-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2819: Summary: IGFS: Aggressively cache secondayr file system metadata to minimize amount of direct FS calls. (was: IGFS: Aggressively cache secondayr file systme metadata to minimize amount of direct FS calls.) > IGFS: Aggressively cache secondayr file system metadata to minimize amount of > direct FS calls. > -- > > Key: IGNITE-2819 > URL: https://issues.apache.org/jira/browse/IGNITE-2819 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > We call secondary file system inside TXes too often to get some metadata. > Instead, when we access any file/dir in DUAL mode for the first time, we > should cache all available metadata from the secondary file system, so that > subsequent calls do not require it any more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2781) IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
[
https://issues.apache.org/jira/browse/IGNITE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-2781:
---
Assignee: Vladimir Ozerov (was: Ivan Veselovsky)
> IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
>
>
> Key: IGNITE-2781
> URL: https://issues.apache.org/jira/browse/IGNITE-2781
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> By default these flags are set to "true" meaning that we will copy values on
> each access.
> We need to set them to {{false}} automatically on node startup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2781) IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
[
https://issues.apache.org/jira/browse/IGNITE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2781.
---
> IGFS: Automatically set "copyOnRead" to "false" for IGFS caches.
>
>
> Key: IGNITE-2781
> URL: https://issues.apache.org/jira/browse/IGNITE-2781
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> By default these flags are set to "true" meaning that we will copy values on
> each access.
> We need to set them to {{false}} automatically on node startup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
