[jira] [Commented] (IGNITE-2344) WebSessionFilter doesn't support session ID renewal

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390496#comment-15390496
 ] 

ASF GitHub Bot commented on IGNITE-2344:


GitHub user samaitra opened a pull request:

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

IGNITE-2344 WebSessionFilter doesn't support session ID renewal



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

$ git pull https://github.com/samaitra/ignite IGNITE-2344

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

https://github.com/apache/ignite/pull/887.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #887


commit c2e9af35635bd92b07ed992a8b0faaeafbedbf41
Author: samaitra 
Date:   2016-06-04T20:39:20Z

IGNITE-2344 WebSessionFilter doesn't support session ID renewal

commit a966f49fb3e7d3f6f22324095b1a10dfb31a261b
Author: samaitra 
Date:   2016-06-04T21:01:13Z

IGNITE-2344 WebSessionFilter doesn't support session ID renewal

commit 7d005184837b93d8edf55b0fef977efc51b94354
Author: samaitra 
Date:   2016-07-22T18:52:32Z

Merge remote-tracking branch 'upstream/master' into IGNITE-2344

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteTxExceptionAbstractSelfTest.java
#   
modules/web/src/main/java/org/apache/ignite/cache/websession/WebSessionFilter.java

commit a6e0d56ee78537d5b1964b86d1ea5242e0708b4a
Author: samaitra 
Date:   2016-07-23T03:32:14Z

IGNITE-2344 WebSessionFilter doesn't support session ID renewal

commit 1eaf006987b4b8140fd68faceb3772fb85b1
Author: samaitra 
Date:   2016-07-23T03:33:44Z

IGNITE-2344 WebSessionFilter doesn't support session ID renewal




> WebSessionFilter doesn't support session ID renewal
> ---
>
> Key: IGNITE-2344
> URL: https://issues.apache.org/jira/browse/IGNITE-2344
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Saikat Maitra
>
> It's quite a common scenario to update a session ID after a user successfully 
> logged in preserving the session content for further usage.
> Ignite's {{WebSessionFilter}} doesn't support such a use case creating a 
> session from scratch.
> To support this behavior we can store a special Cookie that will hold latest 
> session ID. When a session is passed to {{WebSessionFilter}} and the filter 
> detects that this is a fresh session it will check the Cookie in advance. If 
> the Cookie exists and holds an old session ID then the filter will be able to 
> get a session content from the cache using the old ID and put it back using 
> the new ID.



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

[jira] [Commented] (IGNITE-2294) Implement SQL DML (insert, update, delete) clauses.

[Alexander Paschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390461#comment-15390461
 ] 

Alexander Paschenko commented on IGNITE-2294:
-

I have implemented "naive" version of MERGE statement (YAY!, though of course 
it still is a very long way to go).
As for now, it only supports inserting at per row basis ("merge into XXX(cols) 
values(row1), (row2)" kind of thing), and does not support subqueries, 
functions and any other fancy stuff. Also it does not, and most likely will 
not, support custom merge key (KEY clause of MERGE statement, see 
http://www.h2database.com/html/grammar.html#merge for grammar details) because 
it violates the idea of strictly set key. (We explicitly set both key and value 
types when we create cache configuration, remember?)
Still, I think one important and interesting thing about this contribution is 
that it includes concept of the key computed/provided by value object. On the 
mailing list Alexey Goncharuk raised concern about how we supply keys for newly 
inserted values - and that's exactly what that concept addresses. So, as for 
now, there is two ways to supply keys for new values - either via literals 
(familiar _key column), or via special field or method. My pull request (that 
is of course to be updated in the nearest future) linked to this issue includes 
demo of both ways in the form of a test - please see 
IgniteCacheMergeSqlQuerySelfTest if you are interested.
Also, the test showcases this feature in "direct" fashion - without using JDBC 
driver: it just invokes newly introduced IgniteCache.update() operation. JDBC 
support is on the way.

Have a nice weekend everyone!

> Implement SQL DML (insert, update, delete) clauses.
> ---
>
> Key: IGNITE-2294
> URL: https://issues.apache.org/jira/browse/IGNITE-2294
> Project: Ignite
>  Issue Type: Wish
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
> Fix For: 1.7
>
>
> We need to add parsing for all the listed SQL commands and translate them 
> into respective cache operations (putIfAbstent, put, remove).



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

[jira] [Commented] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Igor Rudyak (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390380#comment-15390380
 ] 

Igor Rudyak commented on IGNITE-3293:
-

Ilya,

Did you have a chance to check it one more time?

> AWS bootstrap scripts patch for Ignite-Cassandra 
> -
>
> Key: IGNITE-3293
> URL: https://issues.apache.org/jira/browse/IGNITE-3293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Igor Rudyak
>Assignee: Nikolay Tikhonov
> Attachments: aws-linux-fail.zip, logs-aws-linux-1307.zip, 
> logs-aws-linux-fail-1407.zip, logs-cassandra-ignite.zip
>
>
> New version of AWS bootstrap script having:
> 1) Gaglia monitoring
> 2) Allows to manually trigger tests execution multiple times on the same 
> ifstastructure



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

[jira] [Commented] (IGNITE-2680) Terminating running SQL queries

[Alexei Scherbakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390081#comment-15390081
 ] 

Alexei Scherbakov commented on IGNITE-2680:
---

Review changes are almost ready.

> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
>  Labels: important
>
> If to start a long running SQL query over a huge cache will millions of 
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed 
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related 
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;



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

[jira] [Assigned] (IGNITE-1084) [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken

[Milap Wadhwa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Milap Wadhwa reassigned IGNITE-1084:


Assignee: Milap Wadhwa

> [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken
> --
>
> Key: IGNITE-1084
> URL: https://issues.apache.org/jira/browse/IGNITE-1084
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Milap Wadhwa
>Priority: Minor
>  Labels: Muted_test
>
> Test HibernateL2CacheSelfTest#testNaturalIdCache() should be unmuted and 
> fixed.



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

[jira] [Closed] (IGNITE-3389) metadata result set throws NPE when closed

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura closed IGNITE-3389.
---

> metadata result set throws NPE when closed
> --
>
> Key: IGNITE-3389
> URL: https://issues.apache.org/jira/browse/IGNITE-3389
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, odbc, SQL
>Affects Versions: 1.6, 1.7
>Reporter: Alexandre Boudnik
>Assignee: Andrey Gura
>  Labels: easyfix
> Fix For: 1.7
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Need to handle when ResultSet has no cursor. It happened only with client 
> JDBC. This code throws NPE:
> {code}
> public void testMetadataResultSetClose() throws Exception {
> try (Connection conn = DriverManager.getConnection(BASE_URL)) {
> try (ResultSet tables = conn.getMetaData().getTables(null, null, 
> "%", null)) {
> int columnCount = tables.getMetaData().getColumnCount();
> while (tables.next())
> for (int i = 0; i < columnCount; i++)
> tables.getObject(i + 1);
> }
> }
> }
> {code}



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

[jira] [Commented] (IGNITE-3389) metadata result set throws NPE when closed

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389816#comment-15389816
 ] 

Andrey Gura commented on IGNITE-3389:
-

LGTM. Thanks. Merged to master branch.

> metadata result set throws NPE when closed
> --
>
> Key: IGNITE-3389
> URL: https://issues.apache.org/jira/browse/IGNITE-3389
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, odbc, SQL
>Affects Versions: 1.6, 1.7
>Reporter: Alexandre Boudnik
>Assignee: Andrey Gura
>  Labels: easyfix
> Fix For: 1.7
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Need to handle when ResultSet has no cursor. It happened only with client 
> JDBC. This code throws NPE:
> {code}
> public void testMetadataResultSetClose() throws Exception {
> try (Connection conn = DriverManager.getConnection(BASE_URL)) {
> try (ResultSet tables = conn.getMetaData().getTables(null, null, 
> "%", null)) {
> int columnCount = tables.getMetaData().getColumnCount();
> while (tables.next())
> for (int i = 0; i < columnCount; i++)
> tables.getObject(i + 1);
> }
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-3390) ODBC: Add system DSN support for Windows.

[Igor Sapego (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Sapego updated IGNITE-3390:

Description: 
Need to add support for the DSN creation/modification in Windows. To do so we 
will need to create some UI windows with matching fields.

DSN stands for the Data Source Name, and it is actually list of options for the 
ODBC driver which can be used to establish connection. In our case it is set of 
the host name, tcp port and cache name to which connection should be 
established. In Windows it seems to be common practice to use "ODBC Data Source 
Administrator" system tool to configure DNS for the ODBC driver. "ODBC Data 
Source Administrator" it it's turn uses GUI windows to get DSN information from 
the user. So to support this feature, we'd needed to implement GUI window that 
would allow our users to configure their own DSNs.


  was:Need to add support for the DSN creation/modification in Windows. To do 
so we will need to create some UI windows with matching fields.


> ODBC: Add system DSN support for Windows.
> -
>
> Key: IGNITE-3390
> URL: https://issues.apache.org/jira/browse/IGNITE-3390
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
> Attachments: dsn_configuration_window.png
>
>
> Need to add support for the DSN creation/modification in Windows. To do so we 
> will need to create some UI windows with matching fields.
> DSN stands for the Data Source Name, and it is actually list of options for 
> the ODBC driver which can be used to establish connection. In our case it is 
> set of the host name, tcp port and cache name to which connection should be 
> established. In Windows it seems to be common practice to use "ODBC Data 
> Source Administrator" system tool to configure DNS for the ODBC driver. "ODBC 
> Data Source Administrator" it it's turn uses GUI windows to get DSN 
> information from the user. So to support this feature, we'd needed to 
> implement GUI window that would allow our users to configure their own DSNs.



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

[jira] [Commented] (IGNITE-3512) .NET: IBinaryObject.ToBuilder loses type name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389750#comment-15389750
 ] 

ASF GitHub Bot commented on IGNITE-3512:


Github user ptupitsyn closed the pull request at:

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


> .NET: IBinaryObject.ToBuilder loses type name
> -
>
> Key: IGNITE-3512
> URL: https://issues.apache.org/jira/browse/IGNITE-3512
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Steps to reproduce:
> * Create a builder for a string type name, set field, put to cache
> * On another node, read this object, call ToBuilder, call Build
> Type name is not propagated with metadata, which leads to assertion error 
> (with -ea) or "Two binary types have duplicate type ID [typeId=949122880, 
> typeName1=Security, typeName2=null]]" error.
> Unit test:
> {code}
> [Test]
> public void Test()
> {
> using (var grid1 = 
> Ignition.Start(TestUtils.GetTestConfiguration()))
> using (var grid2 = Ignition.Start(new 
> IgniteConfiguration(TestUtils.GetTestConfiguration(false)) {GridName = 
> "grid2"}))
> {
> var cache1 = grid1.CreateCache int>("cache").WithKeepBinary();
> var obj1 = 
> grid1.GetBinary().GetBuilder("myType").SetField("myField", "val").Build();
> cache1[1] = obj1;
> var cache2 = grid2.GetCache int>("cache").WithKeepBinary();
> var obj2 = cache2[1];
> var val = obj2.GetField("myField");
> var obj2Ex = 
> grid2.GetBinary().GetBuilder(obj2).SetField("myField", val + 
> "_modified").Build();
> cache2[2] = obj2Ex;
> }
> }
> {code}
> Workaround is to register the type by name on start:
> {code}
> BinaryConfiguration = new BinaryConfiguration
> {
> Types = new[] {"myType"}
> }
> {code}



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

[jira] [Commented] (IGNITE-3559) CPP: Review Ignite C++ API and provide list of breaking improvements that can be included in Ignite 2.0

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389728#comment-15389728
 ] 

Igor Sapego commented on IGNITE-3559:
-

I've reviewed current API and here is the list of improvements that break 
backward compatibility:
1. Place different enums in separate namespaces or structs. [Explanation why is 
it a good thing to 
do.|http://stackoverflow.com/questions/7090130/enum-in-a-namespace].
2. Replace pointers with references in {{BinaryMapReader::GetNext}}.
3. Replace passing arguments by copy with passing by constant reference in 
{{BinaryWriter::WriteObject}} and {{BinaryRawWriter::WriteObject}} to avoid 
unnecessary copying.
4. For the {{BinaryType}}: 
- All methods should be 'static'.
- Methods {{GetTypeName()}}, {{Read()}} and {{GetNull()}} should pass 
result to caller by reference argument and not by return value to avoid copying 
and temporary objects creation.
5. For the {{BinaryType}}: additionally to the mentioned above, remove 
field {{typ}} and add typedef for the non-pointer type instead.
6. For the method {{QueryCursor::GetAll}} add support for not only vectors but 
for any container. Consider using iterators (preferably) or template type for 
the container.
7. {{Cache}} class: the same issue as above. Methods {{ContainsKeys}}, 
{{GetAll}}, {{PutAll}}, {{LocalEvict}}, {{ClearAll}}, {{LocalClearAll}}, 
{{RemoveAll}}.
8. Everywhere: Replace {{IgniteError}} arguments passed as pointers with 
references.

These all are just proposals so they all are, of course, discussable.

> CPP: Review Ignite C++ API and provide list of breaking improvements that can 
> be included in Ignite 2.0
> ---
>
> Key: IGNITE-3559
> URL: https://issues.apache.org/jira/browse/IGNITE-3559
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.0
>
>
> As there is going to be Ignite 2.0 release soon, It is a good opportunity to 
> improve Ignite C++ API without the need to maintain backward compatibility. 
> Let's collect and discuss all the proposal for the changes in this task and 
> then create matching subtasks for all the accepted proposals.



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

[jira] [Updated] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

[Taras Ledkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov updated IGNITE-3558:
-
Fix Version/s: 1.7

> Affinity task hangs when Collision SPI produces a lot of job rejections & 
> Failover SPI produces many attempts
> -
>
> Key: IGNITE-3558
> URL: https://issues.apache.org/jira/browse/IGNITE-3558
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> The test to reproduce:
> IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest#testJobFinishing
> *Root cause*
> GridJobExecuteResponse isn't set from target node because there is a 
> confusion with GridJobWorker instances in the CollisionContext.
> *Suggestion*
> The method GridJobProcessor.CollisionJobContext.cancel()
> use passiveJobs.remove(jobWorker.getJobId(), jobWorker). 
> *passiveJobs* is a ConcurrentHashMap and GridJobWorker.equals() implements as 
> a equation of jobId.
> So, when two thread try to cancel the two workers with *the same jobIds* we 
> have the case:
> - thread0 remove jobWorker0 & cancel jobWorker0.
> - thread0 put jobWorker1 (because jobWorker0 already removed);
> - thread1: (has a copy of jobWorker0) and try to cancel it.
> - thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
> identify);
> - thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.
> *Proposal*
> Try to use system default equals for the GridJobWorker



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

[jira] [Created] (IGNITE-3559) CPP: Review Ignite C++ API and provide list of breaking improvements that can be included in Ignite 2.0

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3559:
---

 Summary: CPP: Review Ignite C++ API and provide list of breaking 
improvements that can be included in Ignite 2.0
 Key: IGNITE-3559
 URL: https://issues.apache.org/jira/browse/IGNITE-3559
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.0


As there is going to be Ignite 2.0 release soon, It is a good opportunity to 
improve Ignite C++ API without the need to maintain backward compatibility. 
Let's collect and discuss all the proposal for the changes in this task and 
then create matching subtasks for all the accepted proposals.



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

[jira] [Updated] (IGNITE-3504) .NET: IBinaryObjectBuilder setter methods do not work

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3504:
---
Description: 
SetShortField and other such methods are not tested and do not work properly.

Workaround is to use generic SetField method.

  was:SetShortField and other such methods are not tested and do not work 
properly


> .NET: IBinaryObjectBuilder setter methods do not work
> -
>
> Key: IGNITE-3504
> URL: https://issues.apache.org/jira/browse/IGNITE-3504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>
> SetShortField and other such methods are not tested and do not work properly.
> Workaround is to use generic SetField method.



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

[jira] [Updated] (IGNITE-3504) .NET: IBinaryObjectBuilder setter methods do not work

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3504:
---
Summary: .NET: IBinaryObjectBuilder setter methods do not work  (was: .NET: 
Improve IBinaryObjectBuilder test coverage)

> .NET: IBinaryObjectBuilder setter methods do not work
> -
>
> Key: IGNITE-3504
> URL: https://issues.apache.org/jira/browse/IGNITE-3504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>
> Most methods are not even used anywhere.



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

[jira] [Updated] (IGNITE-3504) .NET: IBinaryObjectBuilder setter methods do not work

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3504:
---
Description: SetShortField and other such methods are not tested and do not 
work properly  (was: Most methods are not even used anywhere.)

> .NET: IBinaryObjectBuilder setter methods do not work
> -
>
> Key: IGNITE-3504
> URL: https://issues.apache.org/jira/browse/IGNITE-3504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>
> SetShortField and other such methods are not tested and do not work properly



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

[jira] [Issue Comment Deleted] (IGNITE-3504) .NET: IBinaryObjectBuilder setter methods do not work

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3504:
---
Comment: was deleted

(was: Apparently, there are bugs in SetShortField and other primitive setter 
methods.)

> .NET: IBinaryObjectBuilder setter methods do not work
> -
>
> Key: IGNITE-3504
> URL: https://issues.apache.org/jira/browse/IGNITE-3504
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>
> SetShortField and other such methods are not tested and do not work properly



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

[jira] [Comment Edited] (IGNITE-3476) Node started within SpringCacheManager does not inject Spring resources

[Eduard Shangareev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389516#comment-15389516
 ] 

Eduard Shangareev edited comment on IGNITE-3476 at 7/22/16 1:44 PM:


# Now {{SpringCacheManager}} and {{SpringTransactionManager}} implement 
{{ApplicationContextAware}} interface.
# {{Ignition.start}} calls were replaced by {{IgniteSpring.start}} calls. 
# New tests were added, which test this issue.

Link to PR:
https://github.com/apache/ignite/pull/885


was (Author: edshanggg):
# Now {{SpringCacheManager}} and {{SpringTransactionManager}} implement 
{{ApplicationContextAware}} interface.
# {{Ignition.start}} calls was replaced by {{IgniteSpring.start}} calls. 
# New tests were added, which test this issue.

> Node started within SpringCacheManager does not inject Spring resources
> ---
>
> Key: IGNITE-3476
> URL: https://issues.apache.org/jira/browse/IGNITE-3476
> Project: Ignite
>  Issue Type: Bug
>  Components: ignite-spring
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 1.7
>
>
> {{SpringCacheManager}} uses {{Ignition.start(..)}} methods to start the node 
> and therefore this node is not application context aware. {{@SpringResource}} 
> and {{@SpringApplicationContextResource}} annotations do not work.
> To fix this, {{SpringCacheManager}} should implement 
> {{ApplicationContextAware}} interface and start the node using 
> {{IgniteSpring.start(..)}} methods, providing the application context.



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

[jira] [Commented] (IGNITE-3476) Node started within SpringCacheManager does not inject Spring resources

[Eduard Shangareev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389516#comment-15389516
 ] 

Eduard Shangareev commented on IGNITE-3476:
---

# Now {{SpringCacheManager}} and {{SpringTransactionManager}} implement 
{{ApplicationContextAware}} interface.
# {{Ignition.start}} calls was replaced by {{IgniteSpring.start}} calls. 
# New tests were added, which test this issue.

> Node started within SpringCacheManager does not inject Spring resources
> ---
>
> Key: IGNITE-3476
> URL: https://issues.apache.org/jira/browse/IGNITE-3476
> Project: Ignite
>  Issue Type: Bug
>  Components: ignite-spring
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 1.7
>
>
> {{SpringCacheManager}} uses {{Ignition.start(..)}} methods to start the node 
> and therefore this node is not application context aware. {{@SpringResource}} 
> and {{@SpringApplicationContextResource}} annotations do not work.
> To fix this, {{SpringCacheManager}} should implement 
> {{ApplicationContextAware}} interface and start the node using 
> {{IgniteSpring.start(..)}} methods, providing the application context.



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

[jira] [Assigned] (IGNITE-3513) Cleanup worker is placed in the Thread's waiting queue using Thread.sleep method

[Eduard Shangareev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduard Shangareev reassigned IGNITE-3513:
-

Assignee: Eduard Shangareev  (was: Andrey Gura)

> Cleanup worker is placed in the Thread's waiting queue using Thread.sleep 
> method
> 
>
> Key: IGNITE-3513
> URL: https://issues.apache.org/jira/browse/IGNITE-3513
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Eduard Shangareev
> Fix For: 1.7
>
>
> There is a bug in current implementation of 
> {{GridCacheTtlManager#CleanupWorker}}.
> Refer to the implementation's code snippet and the details below.
> {code}
> EntryWrapper first = pendingEntries.firstx();
>  if (first != null) {
>long waitTime = first.expireTime - U.currentTimeMillis();
>if (waitTime > 0)
>   U.sleep(waitTime);
>  }
> {code}
> 1. Put first item with TTL = 1 hour. CleanupWorker will go to sleep for 1 
> hour.
> 2. Put second item with TTL = 1 minute. Since 
> CleanupWorker's thread sleeps now, second item will not be expired at the 
> time.
> NOTE: This scenario is easily to reproducible if first and second items are 
> put into cache asynchronously. If try to put them in same thread one-by-one 
> expiration may work fine.



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

[jira] [Closed] (IGNITE-3024) Possible deadlock in services when Spring is used

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov closed IGNITE-3024.

Assignee: (was: Semen Boikov)

> Possible deadlock in services when Spring is used
> -
>
> Key: IGNITE-3024
> URL: https://issues.apache.org/jira/browse/IGNITE-3024
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>  Labels: community, customer, important
> Fix For: 1.7
>
>
> Resource injection in service processor happens inside synchronized block 
> (see {{redeploy()}} method). During injection Spring will acquire its global 
> bean factory lock:
> {noformat}
> "srvc-deploy-#54%xxx%":
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:187)
>   - waiting to lock <0x0006c03e2290> (a 
> java.util.concurrent.ConcurrentHashMap)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:173)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:240)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:956)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceSpringBeanInjector.inject(GridResourceSpringBeanInjector.java:65)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceIoc.injectInternal(GridResourceIoc.java:172)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceIoc.inject(GridResourceIoc.java:97)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:510)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:957)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:873)
>   - locked <0x00077ffd4e50> (a java.util.ArrayList)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$4400(GridServiceProcessor.java:94)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$AssignmentListener$1.run0(GridServiceProcessor.java:1348)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$BusyRunnable.run(GridServiceProcessor.java:1399)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   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}
> If some Spring bean creates a service proxy during initialization, we can get 
> a deadlock:
> {noformat}
> "localhost-startStop-1":
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceContext(GridServiceProcessor.java:613)
>   - waiting to lock <0x00077ffd4e50> (a java.util.ArrayList)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceProxy(GridServiceProcessor.java:633)
>   at 
> org.apache.ignite.internal.IgniteServicesImpl.serviceProxy(IgniteServicesImpl.java:232)
>   ...
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
>   at 
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1119)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1014)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
>   at 
> 

[jira] [Created] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-3558:


 Summary: Affinity task hangs when Collision SPI produces a lot of 
job rejections & Failover SPI produces many attempts
 Key: IGNITE-3558
 URL: https://issues.apache.org/jira/browse/IGNITE-3558
 Project: Ignite
  Issue Type: Bug
  Components: compute
Reporter: Taras Ledkov
Assignee: Taras Ledkov


The test to reproduce:
IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest#testJobFinishing

*Root cause*
GridJobExecuteResponse isn't set from target node because there is a confusion 
with GridJobWorker instances in the CollisionContext.

*Suggestion*
The method GridJobProcessor.CollisionJobContext.cancel()
use passiveJobs.remove(jobWorker.getJobId(), jobWorker). 
*passiveJobs* is a ConcurrentHashMap and GridJobWorker.equals() implements as a 
equation of jobId.

So, when two thread try to cancel the two workers with *the same jobIds* we 
have the case:
- thread0 remove jobWorker0 & cancel jobWorker0.
- thread0 put jobWorker1 (because jobWorker0 already removed);
- thread1: (has a copy of jobWorker0) and try to cancel it.
- thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
identify);
- thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.

*Proposal*
Try to use system default equals for the GridJobWorker



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

[jira] [Resolved] (IGNITE-3024) Possible deadlock in services when Spring is used

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov resolved IGNITE-3024.
--
Resolution: Fixed

> Possible deadlock in services when Spring is used
> -
>
> Key: IGNITE-3024
> URL: https://issues.apache.org/jira/browse/IGNITE-3024
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
>  Labels: community, customer, important
> Fix For: 1.7
>
>
> Resource injection in service processor happens inside synchronized block 
> (see {{redeploy()}} method). During injection Spring will acquire its global 
> bean factory lock:
> {noformat}
> "srvc-deploy-#54%xxx%":
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:187)
>   - waiting to lock <0x0006c03e2290> (a 
> java.util.concurrent.ConcurrentHashMap)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:173)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:240)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:956)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceSpringBeanInjector.inject(GridResourceSpringBeanInjector.java:65)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceIoc.injectInternal(GridResourceIoc.java:172)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceIoc.inject(GridResourceIoc.java:97)
>   at 
> org.apache.ignite.internal.processors.resource.GridResourceProcessor.inject(GridResourceProcessor.java:510)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:957)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:873)
>   - locked <0x00077ffd4e50> (a java.util.ArrayList)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$4400(GridServiceProcessor.java:94)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$AssignmentListener$1.run0(GridServiceProcessor.java:1348)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$BusyRunnable.run(GridServiceProcessor.java:1399)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   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}
> If some Spring bean creates a service proxy during initialization, we can get 
> a deadlock:
> {noformat}
> "localhost-startStop-1":
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceContext(GridServiceProcessor.java:613)
>   - waiting to lock <0x00077ffd4e50> (a java.util.ArrayList)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceProxy(GridServiceProcessor.java:633)
>   at 
> org.apache.ignite.internal.IgniteServicesImpl.serviceProxy(IgniteServicesImpl.java:232)
>   ...
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
>   at 
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1119)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1014)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
>   at 
> 

[jira] [Closed] (IGNITE-3361) Service is not redeployed after a node is left topology

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov closed IGNITE-3361.

Assignee: (was: Semen Boikov)

> Service is not redeployed after a node is left topology
> ---
>
> Key: IGNITE-3361
> URL: https://issues.apache.org/jira/browse/IGNITE-3361
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Priority: Blocker
> Fix For: 1.7
>
> Attachments: SingletonServiceLostAfterToplogyChangeMain.java
>
>
> In attach you will find an example demonstrating the issue when a service is 
> not being redeployed after several nodes are started and stopped.
> The stack trace of the issue is the following
> {code}
> Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
> find deployed service: DummyService
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ProxyInvocationHandler.invoke(GridServiceProxy.java:168)
>   at com.sun.proxy.$Proxy24.foo(Unknown Source)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.failingSequence(SingletonServiceLostAfterToplogyChangeMain.java:95)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.main(SingletonServiceLostAfterToplogyChangeMain.java:18)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}



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

[jira] [Resolved] (IGNITE-3361) Service is not redeployed after a node is left topology

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov resolved IGNITE-3361.
--
Resolution: Fixed

Fixed in master (commit 55e616f).

> Service is not redeployed after a node is left topology
> ---
>
> Key: IGNITE-3361
> URL: https://issues.apache.org/jira/browse/IGNITE-3361
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.7
>
> Attachments: SingletonServiceLostAfterToplogyChangeMain.java
>
>
> In attach you will find an example demonstrating the issue when a service is 
> not being redeployed after several nodes are started and stopped.
> The stack trace of the issue is the following
> {code}
> Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
> find deployed service: DummyService
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ProxyInvocationHandler.invoke(GridServiceProxy.java:168)
>   at com.sun.proxy.$Proxy24.foo(Unknown Source)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.failingSequence(SingletonServiceLostAfterToplogyChangeMain.java:95)
>   at 
> org.apache.ignite.examples.SingletonServiceLostAfterToplogyChangeMain.main(SingletonServiceLostAfterToplogyChangeMain.java:18)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}



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

[jira] [Updated] (IGNITE-3557) Hadoop: integrate with Ambary management console.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3557:

Labels: roadmap  (was: )

> Hadoop: integrate with Ambary management console.
> -
>
> Key: IGNITE-3557
> URL: https://issues.apache.org/jira/browse/IGNITE-3557
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> This will greatly simplify IGFS cluster management.



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

[jira] [Created] (IGNITE-3557) Hadoop: integrate with Ambary management console.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3557:
---

 Summary: Hadoop: integrate with Ambary management console.
 Key: IGNITE-3557
 URL: https://issues.apache.org/jira/browse/IGNITE-3557
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


This will greatly simplify IGFS cluster management.



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

[jira] [Created] (IGNITE-3556) IGFS: Support external changes to the secondary file system.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3556:
---

 Summary: IGFS: Support external changes to the secondary file 
system.
 Key: IGNITE-3556
 URL: https://issues.apache.org/jira/browse/IGNITE-3556
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 2.0


Currently if secondary file system is changed from the outside, IGFS will stop 
working. We need to support ability to survive external change. It means that 
we must very carefully review every single file system operation and see how it 
should behave in this scenario.



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

[jira] [Updated] (IGNITE-3556) IGFS: Support external changes to the secondary file system.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3556:

Labels: roadmap  (was: )

> IGFS: Support external changes to the secondary file system.
> 
>
> Key: IGNITE-3556
> URL: https://issues.apache.org/jira/browse/IGNITE-3556
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: roadmap
> Fix For: 2.0
>
>
> Currently if secondary file system is changed from the outside, IGFS will 
> stop working. We need to support ability to survive external change. It means 
> that we must very carefully review every single file system operation and see 
> how it should behave in this scenario.



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

[jira] [Commented] (IGNITE-3390) ODBC: Add system DSN support for Windows.

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389430#comment-15389430
 ] 

Igor Sapego commented on IGNITE-3390:
-

Vladimir,

1) Currently, there are two arguments in connection string - "Server" and 
"Port", so it is going to be confusing for users to configure "Port" parameter 
if there would not be such a field. I propose to change UI when we will change 
the way addresses are specified in ODBC and leave it "as is" for current 
approach.

2) There are actually no "not-required" fields, as every field is required 
currently.

> ODBC: Add system DSN support for Windows.
> -
>
> Key: IGNITE-3390
> URL: https://issues.apache.org/jira/browse/IGNITE-3390
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
> Attachments: dsn_configuration_window.png
>
>
> Need to add support for the DSN creation/modification in Windows. To do so we 
> will need to create some UI windows with matching fields.



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

[jira] [Updated] (IGNITE-3555) IGFS: Expose IGFS as POSIX file system to OS.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3555:

Labels: roadmap  (was: )

> IGFS: Expose IGFS as POSIX file system to OS.
> -
>
> Key: IGNITE-3555
> URL: https://issues.apache.org/jira/browse/IGNITE-3555
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> This way users will be able to mount IGFS and work with it as with any other 
> file system.



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

[jira] [Created] (IGNITE-3555) IGFS: Expose IGFS as POSIX file system to OS.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3555:
---

 Summary: IGFS: Expose IGFS as POSIX file system to OS.
 Key: IGNITE-3555
 URL: https://issues.apache.org/jira/browse/IGNITE-3555
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


This way users will be able to mount IGFS and work with it as with any other 
file system.



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

[jira] [Updated] (IGNITE-3554) IGFS: Support cross-mode operations.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3554:

Labels: roadmap  (was: )

> IGFS: Support cross-mode operations.
> 
>
> Key: IGNITE-3554
> URL: https://issues.apache.org/jira/browse/IGNITE-3554
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> We need to support operations when certain files/diretories are moved between 
> modes. This affects operations where two directories are involved, or several 
> paths are affected:
> 1) create/append
> 2) mkdirs
> 3) rename
> 4) delete



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

[jira] [Commented] (IGNITE-3554) IGFS: Support cross-mode operations.

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389424#comment-15389424
 ] 

Vladimir Ozerov commented on IGNITE-3554:
-

When implemented it will allow to host certain files (e.g. temp Hadoop job 
data) only in-memory, thus improving performance.

> IGFS: Support cross-mode operations.
> 
>
> Key: IGNITE-3554
> URL: https://issues.apache.org/jira/browse/IGNITE-3554
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> We need to support operations when certain files/diretories are moved between 
> modes. This affects operations where two directories are involved, or several 
> paths are affected:
> 1) create/append
> 2) mkdirs
> 3) rename
> 4) delete



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

[jira] [Created] (IGNITE-3554) IGFS: Support cross-mode operations.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3554:
---

 Summary: IGFS: Support cross-mode operations.
 Key: IGNITE-3554
 URL: https://issues.apache.org/jira/browse/IGNITE-3554
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


We need to support operations when certain files/diretories are moved between 
modes. This affects operations where two directories are involved, or several 
paths are affected:
1) create/append
2) mkdirs
3) rename
4) delete




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

[jira] [Created] (IGNITE-3553) Implement internal light-weight closure execution.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3553:
---

 Summary: Implement internal light-weight closure execution.
 Key: IGNITE-3553
 URL: https://issues.apache.org/jira/browse/IGNITE-3553
 Project: Ignite
  Issue Type: Sub-task
  Components: compute, IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.7


The main goal is speed. No failover. No sessions. No injections. Just extremely 
compact message and execution.



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

[jira] [Updated] (IGNITE-3333) IGFS: Allow for ATOMIC data cache.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3552

> IGFS: Allow for ATOMIC data cache.
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> Currently data cache must be transactional. It means that some updates even 
> on single key will require 2PC. Instead, it makes sense to try change update 
> logic to work always on single keys. In this case we will be able to switch 
> to ATOMIC cache, what could improve performance dramatically.



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

[jira] [Updated] (IGNITE-3343) IGFS: Do not query secondary file system properties during create/append/mkdirs.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3343:

Issue Type: Sub-task  (was: Improvement)
Parent: IGNITE-3552

> IGFS: Do not query secondary file system properties during 
> create/append/mkdirs.
> 
>
> Key: IGNITE-3343
> URL: https://issues.apache.org/jira/browse/IGNITE-3343
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> Currently when we create something in a secondary file system, we perform 
> additional calls to the secondary file system to get file/directory info. 
> This significantly slows down structural operations, while usually it is not 
> really needed in most cases.
> We should do the following:
> 1) Do not write modification time, access time and properties for DUAL 
> entries. Instead, we should propagate "info" and "listFiles" calls to 
> secondary file system right away.
> 2) For {{create()}} we do not need length, as the file is either created from 
> scratch, or truncated.
> 3) For {{append()}} we need to know current length, so the second file system 
> call appears to be inevitable.



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

[jira] [Updated] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3335:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3552

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important, performance
> Fix For: 1.7
>
>




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

[jira] [Updated] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3332:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3552

> IGFS: Use task for file unlock routine on client nodes.
> ---
>
> Key: IGNITE-3332
> URL: https://issues.apache.org/jira/browse/IGNITE-3332
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important, perfomance
> Fix For: 1.7
>
>




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

[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3331:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3552

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: important, perfomance
> Fix For: 1.7
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Updated] (IGNITE-3552) IGFS: Performance improvements.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3552:

Labels: roadmap  (was: )

> IGFS: Performance improvements.
> ---
>
> Key: IGNITE-3552
> URL: https://issues.apache.org/jira/browse/IGNITE-3552
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 1.7
>
>
> This is an umbrella ticket for all recent performance improvements planned 
> for IGFS.



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

[jira] [Created] (IGNITE-3552) IGFS: Performance improvements.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3552:
---

 Summary: IGFS: Performance improvements.
 Key: IGNITE-3552
 URL: https://issues.apache.org/jira/browse/IGNITE-3552
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 1.7


This is an umbrella ticket for all recent performance improvements planned for 
IGFS.



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

[jira] [Assigned] (IGNITE-3300) ArrayIndexOutOfBoundsException: -1 during capitalization benchmark running

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov reassigned IGNITE-3300:


Assignee: Semen Boikov

> ArrayIndexOutOfBoundsException: -1 during capitalization benchmark running
> --
>
> Key: IGNITE-3300
> URL: https://issues.apache.org/jira/browse/IGNITE-3300
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Blocker
>
> Test config:
> 1 client, 16 servers
> warmup 60
> duration 1h
> preload 5M
> operations: capitalization benchmark
> backups count 1
> After ~30 min after start the following errors occur at the driver:
> {noformat}
> [08:42:51,367][ERROR][sys-#5%null%][GridTaskWorker] Failed to obtain remote 
> job result policy for result from ComputeTask.result(..) method (will fail 
> the whole task): GridJobResultImpl [job=C4V2 
> [r=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure@41013d64],
>  sib=GridJobSiblingImpl 
> [sesId=bfb21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> nodeId=79226bcc-651f-4af7-8d39-fd4019b7708c, isJobDone=false], 
> jobCtx=GridJobContextImpl 
> [jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, timeoutObj=null, 
> attrs={}], node=TcpDiscoveryNode [id=79226bcc-651f-4af7-8d39-fd4019b7708c, 
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47501, 
> /10.20.0.216:47501, /127.0.0.1:47501], discPort=47501, order=5, intOrder=5, 
> lastExchangeTime=1465485122287, loc=false, ver=1.7.0#20160603-sha1:82573436, 
> isClient=false], ex=class o.a.i.compute.ComputeUserUndeclaredException: 
> Failed to execute job due to unexpected runtime exception 
> [jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure,
>  dep=LocalDeployment [super=GridDeployment [ts=1465485111989, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@6da264f1, 
> clsLdrId=cee28b53551-79226bcc-651f-4af7-8d39-fd4019b7708c, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure,
>  sesId=bfb21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> startTime=1465486810898, endTime=9223372036854775807, 
> taskNodeId=a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> clsLdr=sun.misc.Launcher$AppClassLoader@6da264f1, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=a8d91d06-89bd-41a5-8b4f-6a02416dfc63, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1465486811180, 
> endTime=0, ignoreInterrupts=false, state=INIT]]], 
> jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63]], hasRes=true, 
> isCancelled=false, isOccupied=true]
> class org.apache.ignite.IgniteException: Remote job threw user exception 
> (override or implement ComputeTask.result(..) method if you would like to 
> have automatic failover for this exception).
> at 
> org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:912)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:905)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6491)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:905)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:801)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:995)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1220)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 

[jira] [Updated] (IGNITE-2355) Hadoop client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2355:

Fix Version/s: 2.0

> Hadoop client should be able to failover in case of server crash.
> -
>
> Key: IGNITE-2355
> URL: https://issues.apache.org/jira/browse/IGNITE-2355
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Currently we explicitly specify a single IP address of Ignite server for map 
> reduce.
> If it goes down, no jobs can be submitted anymore.
> Looks like we should give user ability to specify multiple addresses, and 
> failover between them. Our thin client (which underlies Hadoop client) is 
> already able to accept multiple addresses.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Updated] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2356:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Updated] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2356:

Fix Version/s: 2.0

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Updated] (IGNITE-2355) Hadoop client should be able to failover in case of server crash.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2355:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3551

> Hadoop client should be able to failover in case of server crash.
> -
>
> Key: IGNITE-2355
> URL: https://issues.apache.org/jira/browse/IGNITE-2355
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Currently we explicitly specify a single IP address of Ignite server for map 
> reduce.
> If it goes down, no jobs can be submitted anymore.
> Looks like we should give user ability to specify multiple addresses, and 
> failover between them. Our thin client (which underlies Hadoop client) is 
> already able to accept multiple addresses.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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

[jira] [Updated] (IGNITE-3534) Hadoop: create factory for UserNameMapper.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3534:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3551

> Hadoop: create factory for UserNameMapper.
> --
>
> Key: IGNITE-3534
> URL: https://issues.apache.org/jira/browse/IGNITE-3534
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We need to be compliant for other parts of Ignite API.



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

[jira] [Updated] (IGNITE-3533) Hadoop: create factory for map-reduce planner.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3533:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3551

> Hadoop: create factory for map-reduce planner.
> --
>
> Key: IGNITE-3533
> URL: https://issues.apache.org/jira/browse/IGNITE-3533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We need it to be compliant with other part of Ignite API.



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

[jira] [Updated] (IGNITE-3532) Hadoop: Move HadoopMapReducePlanner interface to public space.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3532:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3551

> Hadoop: Move HadoopMapReducePlanner interface to public space.
> --
>
> Key: IGNITE-3532
> URL: https://issues.apache.org/jira/browse/IGNITE-3532
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently {{HadoopMapReducePlanner}} is located inside private package, but 
> is exposed to {{HadoopConfiguration}}. 
> We must move this interface to public package.



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

[jira] [Updated] (IGNITE-3551) Hadoop: Improve usability for Apache Ignite 2.0

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3551:

Labels: roadmap  (was: )

> Hadoop: Improve usability for Apache Ignite 2.0
> ---
>
> Key: IGNITE-3551
> URL: https://issues.apache.org/jira/browse/IGNITE-3551
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> This is an umbrella ticket to host all IGFS usability improvements targeted 
> for Apache Ignite 2.0.



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

[jira] [Created] (IGNITE-3551) Hadoop: Improve usability for Apache Ignite 2.0

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3551:
---

 Summary: Hadoop: Improve usability for Apache Ignite 2.0
 Key: IGNITE-3551
 URL: https://issues.apache.org/jira/browse/IGNITE-3551
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


This is an umbrella ticket to host all IGFS usability improvements targeted for 
Apache Ignite 2.0.



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

[jira] [Updated] (IGNITE-3535) Hadoop: make IgniteHadoopWeightedMapReducePlanner default one.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3535:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3551

> Hadoop: make IgniteHadoopWeightedMapReducePlanner default one.
> --
>
> Key: IGNITE-3535
> URL: https://issues.apache.org/jira/browse/IGNITE-3535
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Most probably we should even remove {{IgniteHadoopMapReducePlanner}} 
> implementation as it is too inefficient.



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

[jira] [Updated] (IGNITE-3544) IGFS: Review info() semantics - should it return null or throw exception if file doesn't exist?

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3544:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review info() semantics - should it return null or throw exception if 
> file doesn't exist?
> ---
>
> Key: IGNITE-3544
> URL: https://issues.apache.org/jira/browse/IGNITE-3544
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Throw exception: clean and simple semantics, but if Hadoop/Spark/etc. 
> products return null in this case, we could end up with hot path where 
> exception is thrown. This would render bad performance.
> 2) Return null: always good perf, but additional null-checks will be required.
> Alternatively:
> - Have a method with exception semantics on public API, but use method with 
> null semantics for {{IgniteHadoopFileSystem}}.



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

[jira] [Updated] (IGNITE-2357) IGFS: Create factory for IgfsSecondaryFileSystem

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2357:

Summary: IGFS: Create factory for IgfsSecondaryFileSystem  (was: Create 
factory for IgfsSecondaryFileSystem)

> IGFS: Create factory for IgfsSecondaryFileSystem
> 
>
> Key: IGNITE-2357
> URL: https://issues.apache.org/jira/browse/IGNITE-2357
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> Most of our pluggable components are serializable, so that 
> IgniteConfiguration can be converted to bytes and transferred over wire.
> This is not the case for IgfsSecondaryFileSystem. 
> There are several ways to fix that:
> 1) Mark IgfsSecondaryFileSystem as Serializable - simple and straightforward 
> solution. But what if user cannot serialize some internals of his file system 
> implementation?
> 2) Abstract out file system and user serializable Factory instead - this is 
> how things work in some other places (e.g. cache store factory).



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

[jira] [Updated] (IGNITE-3545) IGFS: Review exceptions in secondary file system interface.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3545:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review exceptions in secondary file system interface.
> ---
>
> Key: IGNITE-3545
> URL: https://issues.apache.org/jira/browse/IGNITE-3545
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Possible solutions:
> 1) Throw {{IgniteException}} - looks to broad, but who cares?
> 2) Throw {{IOException}} - better fits into general understanding of what 
> file system is. Having it in the interface will reduce try-catch boilerplate 
> in concrete implementations.
> Any other ideas?



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

[jira] [Updated] (IGNITE-3549) IGFS: Switch "accessTime" and "modification" time in setTimes() method.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3549:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Switch "accessTime" and "modification" time in setTimes() method.
> ---
>
> Key: IGNITE-3549
> URL: https://issues.apache.org/jira/browse/IGNITE-3549
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> This way we will be more similar to Hadoop {{FileSystem}} API where 
> modification time comes first.



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

[jira] [Updated] (IGNITE-3523) IGFS: Remove "initialize default path modes" feature.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3523:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Remove "initialize default path modes" feature.
> -
>
> Key: IGNITE-3523
> URL: https://issues.apache.org/jira/browse/IGNITE-3523
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently IGFS can create several paths by default, which will forcefully 
> work in different modes. This will never require in practice, but caused some 
> problems, e.g. performance degradation in our Hadoop FileSystem implementaions
> Let's just remove that feature along with relevant property in 
> {{FileSystemConfiguration}}.



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

[jira] [Updated] (IGNITE-3546) IGFS: Review events subsystem.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3546:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review events subsystem.
> --
>
> Key: IGNITE-3546
> URL: https://issues.apache.org/jira/browse/IGNITE-3546
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently we have different event types for various file system operations. 
> But we do not fire them always. E.g. if the path {{/a}} is removed, then we 
> will fire only one event. We will not fire events for {{/a/b}}.
> Is it fine or not? Do we need these events at all or not? May be we want to 
> configure event handling somehow? May be users would like to listen such 
> events? Need to think about it.



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

[jira] [Updated] (IGNITE-3531) IGFS: Rename format() to clear().

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3531:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Rename format() to clear().
> -
>
> Key: IGNITE-3531
> URL: https://issues.apache.org/jira/browse/IGNITE-3531
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently format() method is used to quickly clear all IGFS data without 
> touching secondary file system. This way it is equal to 
> {{IgniteCache.clear()}} semantics. 
> Let's rename format -> clear for consistency.



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

[jira] [Updated] (IGNITE-3529) IGFS: Simplify meta and data cache configuration.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3529:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Simplify meta and data cache configuration.
> -
>
> Key: IGNITE-3529
> URL: https://issues.apache.org/jira/browse/IGNITE-3529
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently IGFS configuration is rather complex because user have to manually 
> do the following:
> 1) Configure meta cache
> 2) Configure data cache 
> 3) Wire them up with IGFS through {{FileSystemConfiguration.*CacheName}} 
> properties. 
> Instead, I propose to do the following:
> 1) Add two properties directly to {{FileSystemConfiguration}}:
> - dataCacheConfiguration
> - metaCacheConfiguration
> 2) Names of these cache will be ignored and overwritten with cache name 
> unique to concrete IGFS . E.g. *_data and *_meta, where * is IGFS name.
> 3) *THE MOST IMPORTANT THING* - provide sensible defaults. 
> This way normally user will not bother about cache config at all. He will 
> only need to add IGFS config bean and set it's name.



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

[jira] [Updated] (IGNITE-3529) IGFS: Simplify meta and data cache configuration.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3529:

Priority: Critical  (was: Major)

> IGFS: Simplify meta and data cache configuration.
> -
>
> Key: IGNITE-3529
> URL: https://issues.apache.org/jira/browse/IGNITE-3529
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently IGFS configuration is rather complex because user have to manually 
> do the following:
> 1) Configure meta cache
> 2) Configure data cache 
> 3) Wire them up with IGFS through {{FileSystemConfiguration.*CacheName}} 
> properties. 
> Instead, I propose to do the following:
> 1) Add two properties directly to {{FileSystemConfiguration}}:
> - dataCacheConfiguration
> - metaCacheConfiguration
> 2) Names of these cache will be ignored and overwritten with cache name 
> unique to concrete IGFS . E.g. *_data and *_meta, where * is IGFS name.
> 3) *THE MOST IMPORTANT THING* - provide sensible defaults. 
> This way normally user will not bother about cache config at all. He will 
> only need to add IGFS config bean and set it's name.



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

[jira] [Updated] (IGNITE-3528) IGFS: Review IgfsSecondaryFileSystem.open() method return type.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3528:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review IgfsSecondaryFileSystem.open() method return type.
> ---
>
> Key: IGNITE-3528
> URL: https://issues.apache.org/jira/browse/IGNITE-3528
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently we return weird {{IgfsSecondaryFileSystemPositionedReadable}} 
> interface. It's goal is clear - we need to have a seekable stream. Need to 
> review it accurately and decide whether any changes or renamings are required 
> here.



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

[jira] [Updated] (IGNITE-3527) IGFS: Review "rename", "delete" and "mkdirs" return types in IgniteFileSystem and IgfsSecondaryFileSystem:

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3527:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review "rename", "delete" and "mkdirs" return types in IgniteFileSystem 
> and IgfsSecondaryFileSystem:
> --
>
> Key: IGNITE-3527
> URL: https://issues.apache.org/jira/browse/IGNITE-3527
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently their semantics are not clear:
> - boolean delete()
> - void mkdirs()
> - void rename();
> They all must have the same return type and semantics. The question is which 
> semantics to choose:
> 1) Return boolean and (almost) never throw exceptions. This is "JDK way". I 
> personally do not like it because user will have to both check for true/false 
> and use try/catch.
> 2) Return void and throw exception if something went wrong. 



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

[jira] [Updated] (IGNITE-3526) IGFS: Review "perNodeBatchSize" and "perNodeParallelBatchCount" properties.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3526:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Review "perNodeBatchSize" and "perNodeParallelBatchCount" properties.
> ---
>
> Key: IGNITE-3526
> URL: https://issues.apache.org/jira/browse/IGNITE-3526
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> These properties are extremely weird form user perspective. We need to review 
> how they are actually used inside IGFS code and either remove them or 
> refactor to something more useful.



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

[jira] [Updated] (IGNITE-3524) IGFS: Do not allow nulls for FileSystemConfiguration.name.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3524:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Do not allow nulls for FileSystemConfiguration.name.
> --
>
> Key: IGNITE-3524
> URL: https://issues.apache.org/jira/browse/IGNITE-3524
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> As a part of our general approach, let's do not allow nulls as IGFS names.



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

[jira] [Updated] (IGNITE-3522) IGFS: Rename "streamBufferSize" to "bufferSize" in FileSystemConfiguration.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3522:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Rename "streamBufferSize" to "bufferSize" in FileSystemConfiguration.
> ---
>
> Key: IGNITE-3522
> URL: https://issues.apache.org/jira/browse/IGNITE-3522
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> It will look more consistent with "blockSize" property.



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

[jira] [Updated] (IGNITE-3525) IGFS: Move fragmentizer-related properties into a separate class.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3525:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Move fragmentizer-related properties into a separate class.
> -
>
> Key: IGNITE-3525
> URL: https://issues.apache.org/jira/browse/IGNITE-3525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Let's move the following properties there:
> - fragmentizerConccurrentFiles;
> - fragmentizerThrottlingDelay;
> - fragmentizerThrottlingBlockLength.



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

[jira] [Updated] (IGNITE-3550) IGFS: Improve usability for Apache Ignite 2.0.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3550:

Labels: roadmap  (was: )

> IGFS: Improve usability for Apache Ignite 2.0.
> --
>
> Key: IGNITE-3550
> URL: https://issues.apache.org/jira/browse/IGNITE-3550
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: roadmap
> Fix For: 2.0
>
>
> This is an umbrella ticket to host all IGFS usability improvements targeted 
> for Apache Ignite 2.0.



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

[jira] [Updated] (IGNITE-3520) IGFS: Remove task execution methods.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3520:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Remove task execution methods.
> 
>
> Key: IGNITE-3520
> URL: https://issues.apache.org/jira/browse/IGNITE-3520
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We have several task execution methods on IGFS API. They were never used in 
> practice because normally users will achieve the same things using Hadoop or 
> Spark frameworks. 
> I propose to remove them altogether. This way we will be able to focus solely 
> on file system semantics.



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

[jira] [Updated] (IGNITE-3521) IGFS: Remove "max space" notion.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3521:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Remove "max space" notion.
> 
>
> Key: IGNITE-3521
> URL: https://issues.apache.org/jira/browse/IGNITE-3521
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We have "max space" concept in IGFS which governs maximum amount of local 
> data available for IGFS. This concept looks a bit weird because we do not 
> have the same thing in caches. 
> Moreover, we have several conflicting configuration parameters:
> 1) {{IgfsPerBlockLruEvictionPolicy}} where we also can specify maximum size.
> 2) {{CacheConfiguration.offheapMaxMemory}} which also governs evictions.
> It looks like we should simply remove "max space" property from IGFS 
> configuration and do not control it anyhow.



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

[jira] [Updated] (IGNITE-2357) Create factory for IgfsSecondaryFileSystem

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2357:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> Create factory for IgfsSecondaryFileSystem
> --
>
> Key: IGNITE-2357
> URL: https://issues.apache.org/jira/browse/IGNITE-2357
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> Most of our pluggable components are serializable, so that 
> IgniteConfiguration can be converted to bytes and transferred over wire.
> This is not the case for IgfsSecondaryFileSystem. 
> There are several ways to fix that:
> 1) Mark IgfsSecondaryFileSystem as Serializable - simple and straightforward 
> solution. But what if user cannot serialize some internals of his file system 
> implementation?
> 2) Abstract out file system and user serializable Factory instead - this is 
> how things work in some other places (e.g. cache store factory).



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

[jira] [Updated] (IGNITE-3536) IGFS: Implement async methods for all base file system operations.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3536:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-3550

> IGFS: Implement async methods for all base file system operations.
> --
>
> Key: IGNITE-3536
> URL: https://issues.apache.org/jira/browse/IGNITE-3536
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> 1) Remove {{IgniteAsyncSupport}} interface
> 2) Implement async counterparts for all FS operations.
> Justification: some structure file system operations might be very 
> time-consuming, so having async counterparts sounds like a good idea.
> The questions is what thread pool will host these tasks.



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

[jira] [Created] (IGNITE-3550) IGFS: Improve usability for Apache Ignite 2.0.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3550:
---

 Summary: IGFS: Improve usability for Apache Ignite 2.0.
 Key: IGNITE-3550
 URL: https://issues.apache.org/jira/browse/IGNITE-3550
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


This is an umbrella ticket to host all IGFS usability improvements targeted for 
Apache Ignite 2.0.



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

[jira] [Resolved] (IGNITE-2303) Allow PROXY mode execution in IGFS

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov resolved IGNITE-2303.
-
Resolution: Duplicate
  Assignee: Vladimir Ozerov

See IGNITE-3376.

> Allow PROXY mode execution in IGFS
> --
>
> Key: IGNITE-2303
> URL: https://issues.apache.org/jira/browse/IGNITE-2303
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Currently we do not allow execution of Igfs commands on PROXY paths. Instead, 
> we assume that user must handle it on his own somehow.
> E.g., IgniteHadoopFileSystem creates its own instance of target FileSystem 
> and use it directly.
> We need to return to normal design when all commands can be executed on 
> IgfsImpl directly.



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

[jira] [Closed] (IGNITE-2303) Allow PROXY mode execution in IGFS

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-2303.
---

> Allow PROXY mode execution in IGFS
> --
>
> Key: IGNITE-2303
> URL: https://issues.apache.org/jira/browse/IGNITE-2303
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Currently we do not allow execution of Igfs commands on PROXY paths. Instead, 
> we assume that user must handle it on his own somehow.
> E.g., IgniteHadoopFileSystem creates its own instance of target FileSystem 
> and use it directly.
> We need to return to normal design when all commands can be executed on 
> IgfsImpl directly.



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

[jira] [Resolved] (IGNITE-2275) Hadoop: restore external code execution.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov resolved IGNITE-2275.
-
Resolution: Duplicate
  Assignee: Vladimir Ozerov

See IGNITE-3167.

> Hadoop: restore external code execution.
> 
>
> Key: IGNITE-2275
> URL: https://issues.apache.org/jira/browse/IGNITE-2275
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Several major problems with internal job execution were revealed:
> 1) Native code cannot run normally.
> 2) Excessive permgen allocations
> 3) We must use some dirty hacks to prevent classloader leaks (see mocked 
> classes in HadoopClassLoader).
> External execution must help us with it. 
> The problem is that it never worked properly. We must restore it and then 
> test very thoroughly.



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

[jira] [Updated] (IGNITE-2303) Allow PROXY mode execution in IGFS

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2303:

Labels:   (was: roadmap)

> Allow PROXY mode execution in IGFS
> --
>
> Key: IGNITE-2303
> URL: https://issues.apache.org/jira/browse/IGNITE-2303
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>
> Currently we do not allow execution of Igfs commands on PROXY paths. Instead, 
> we assume that user must handle it on his own somehow.
> E.g., IgniteHadoopFileSystem creates its own instance of target FileSystem 
> and use it directly.
> We need to return to normal design when all commands can be executed on 
> IgfsImpl directly.



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

[jira] [Updated] (IGNITE-2275) Hadoop: restore external code execution.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2275:

Labels:   (was: roadmap)

> Hadoop: restore external code execution.
> 
>
> Key: IGNITE-2275
> URL: https://issues.apache.org/jira/browse/IGNITE-2275
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Several major problems with internal job execution were revealed:
> 1) Native code cannot run normally.
> 2) Excessive permgen allocations
> 3) We must use some dirty hacks to prevent classloader leaks (see mocked 
> classes in HadoopClassLoader).
> External execution must help us with it. 
> The problem is that it never worked properly. We must restore it and then 
> test very thoroughly.



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

[jira] [Closed] (IGNITE-2275) Hadoop: restore external code execution.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-2275.
---

> Hadoop: restore external code execution.
> 
>
> Key: IGNITE-2275
> URL: https://issues.apache.org/jira/browse/IGNITE-2275
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Several major problems with internal job execution were revealed:
> 1) Native code cannot run normally.
> 2) Excessive permgen allocations
> 3) We must use some dirty hacks to prevent classloader leaks (see mocked 
> classes in HadoopClassLoader).
> External execution must help us with it. 
> The problem is that it never worked properly. We must restore it and then 
> test very thoroughly.



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

[jira] [Updated] (IGNITE-3376) IGFS: Allow direct PROXY mode invocations.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3376:

Labels: roadmap  (was: )

> IGFS: Allow direct PROXY mode invocations.
> --
>
> Key: IGNITE-3376
> URL: https://issues.apache.org/jira/browse/IGNITE-3376
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: roadmap
>
> Currently we do not have special handling for PROXY mode. So we will either 
> hit AssertionError during dev, or will go to incorrect code path in 
> productions systems.
> We need to fix that - PROXY mode should be handled correctly.



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

[jira] [Updated] (IGNITE-1926) Implement IgfsSecondaryFileSystem using java.io.File API

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-1926:

Labels: roadmap  (was: newbie)

> Implement IgfsSecondaryFileSystem using java.io.File API
> 
>
> Key: IGNITE-1926
> URL: https://issues.apache.org/jira/browse/IGNITE-1926
> Project: Ignite
>  Issue Type: Improvement
>  Components: IGFS, newbie
>Reporter: Valentin Kulichenko
>  Labels: roadmap
>
> This will allow to persist IGFS data on the local disk. Currently we have 
> only Hadoop-based implementation.
> Corresponding user thread: 
> http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-td1882.html



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

[jira] [Updated] (IGNITE-3167) Hadoop: restore external execution.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3167:

Labels: roadmap  (was: )

> Hadoop: restore external execution.
> ---
>
> Key: IGNITE-3167
> URL: https://issues.apache.org/jira/browse/IGNITE-3167
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: roadmap
>
> Some time ago we decided to get rid external execution mode. It appears to be 
> a wrong decision.
> Hadoop users rely on its process-per-job nature in lot's places. One of such 
> case could be observed in HiBench Bayes benchmark:
> 1) Job creates something in the local file system through Hadoop FileSystem 
> API.
> 2) Then it tries to get this data using regular java.io.FileReader and 
> relative paths. 
> This doesn't work in embedded mode because our LocalFileSystem wrapper 
> assigns different work dirs for jobs, but process-wide working directory is 
> always the same. As a result, aforementioned benchmark doesn't work in 
> Ignite, but work with standard Hadoop job tracker.
> It seems that we must return external execution back.



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

[jira] [Closed] (IGNITE-3512) .NET: IBinaryObject.ToBuilder loses type name

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-3512.
---

> .NET: IBinaryObject.ToBuilder loses type name
> -
>
> Key: IGNITE-3512
> URL: https://issues.apache.org/jira/browse/IGNITE-3512
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Steps to reproduce:
> * Create a builder for a string type name, set field, put to cache
> * On another node, read this object, call ToBuilder, call Build
> Type name is not propagated with metadata, which leads to assertion error 
> (with -ea) or "Two binary types have duplicate type ID [typeId=949122880, 
> typeName1=Security, typeName2=null]]" error.
> Unit test:
> {code}
> [Test]
> public void Test()
> {
> using (var grid1 = 
> Ignition.Start(TestUtils.GetTestConfiguration()))
> using (var grid2 = Ignition.Start(new 
> IgniteConfiguration(TestUtils.GetTestConfiguration(false)) {GridName = 
> "grid2"}))
> {
> var cache1 = grid1.CreateCache int>("cache").WithKeepBinary();
> var obj1 = 
> grid1.GetBinary().GetBuilder("myType").SetField("myField", "val").Build();
> cache1[1] = obj1;
> var cache2 = grid2.GetCache int>("cache").WithKeepBinary();
> var obj2 = cache2[1];
> var val = obj2.GetField("myField");
> var obj2Ex = 
> grid2.GetBinary().GetBuilder(obj2).SetField("myField", val + 
> "_modified").Build();
> cache2[2] = obj2Ex;
> }
> }
> {code}
> Workaround is to register the type by name on start:
> {code}
> BinaryConfiguration = new BinaryConfiguration
> {
> Types = new[] {"myType"}
> }
> {code}



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

[jira] [Commented] (IGNITE-3515) NullPointerException when stopping IgniteSemaphore and no method has been called previously to initialize semaphore with initializeSemaphore().

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389375#comment-15389375
 ] 

ASF GitHub Bot commented on IGNITE-3515:


Github user kromulan closed the pull request at:

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


> NullPointerException when stopping IgniteSemaphore and no method has been 
> called previously to initialize semaphore with initializeSemaphore().
> ---
>
> Key: IGNITE-3515
> URL: https://issues.apache.org/jira/browse/IGNITE-3515
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Krome Plasma
>Assignee: Krome Plasma
> Fix For: 1.7
>
>
> IgniteSemaphore stop() method does not check if internal synchronization 
> object 'sync' is null hence null pointer exception is thrown.



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

[jira] [Updated] (IGNITE-3549) IGFS: Switch "accessTime" and "modification" time in setTimes() method.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-3549:

Summary: IGFS: Switch "accessTime" and "modification" time in setTimes() 
method.  (was: IGFS: Switch his)

> IGFS: Switch "accessTime" and "modification" time in setTimes() method.
> ---
>
> Key: IGNITE-3549
> URL: https://issues.apache.org/jira/browse/IGNITE-3549
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> This way we will be more similar to Hadoop {{FileSystem}} API where 
> modification time comes first.



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

[jira] [Resolved] (IGNITE-3496) .NET: Identify 2.0 API changes

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn resolved IGNITE-3496.

Resolution: Done

> .NET: Identify 2.0 API changes
> --
>
> Key: IGNITE-3496
> URL: https://issues.apache.org/jira/browse/IGNITE-3496
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.0
>
>
> 2.0 is a chance to introduce breaking changes in the API and fix whatever 
> needs to be fixed.



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

[jira] [Closed] (IGNITE-3496) .NET: Identify 2.0 API changes

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn closed IGNITE-3496.
--

> .NET: Identify 2.0 API changes
> --
>
> Key: IGNITE-3496
> URL: https://issues.apache.org/jira/browse/IGNITE-3496
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.0
>
>
> 2.0 is a chance to introduce breaking changes in the API and fix whatever 
> needs to be fixed.



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

[jira] [Created] (IGNITE-3549) IGFS: Switch his

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3549:
---

 Summary: IGFS: Switch his
 Key: IGNITE-3549
 URL: https://issues.apache.org/jira/browse/IGNITE-3549
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
 Fix For: 2.0


This way we will be more similar to Hadoop {{FileSystem}} API where 
modification time comes first.



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

[jira] [Created] (IGNITE-3548) .NET: Rename ILifecycleBean

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3548:
--

 Summary: .NET: Rename ILifecycleBean
 Key: IGNITE-3548
 URL: https://issues.apache.org/jira/browse/IGNITE-3548
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


Bean is a Java term. 

Either rename this interface to something like ILifecycle, or rework the 
lifecycle notifications to C# event handlers.



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

[jira] [Closed] (IGNITE-3515) NullPointerException when stopping IgniteSemaphore and no method has been called previously to initialize semaphore with initializeSemaphore().

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-3515.
---

> NullPointerException when stopping IgniteSemaphore and no method has been 
> called previously to initialize semaphore with initializeSemaphore().
> ---
>
> Key: IGNITE-3515
> URL: https://issues.apache.org/jira/browse/IGNITE-3515
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Krome Plasma
>Assignee: Krome Plasma
> Fix For: 1.7
>
>
> IgniteSemaphore stop() method does not check if internal synchronization 
> object 'sync' is null hence null pointer exception is thrown.



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

[jira] [Commented] (IGNITE-3512) .NET: IBinaryObject.ToBuilder loses type name

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389364#comment-15389364
 ] 

Pavel Tupitsyn commented on IGNITE-3512:


Ctor call fixed, good point.

Yes, it should fit into IGNITE-2703, actually I've copied a piece of code from 
there.

> .NET: IBinaryObject.ToBuilder loses type name
> -
>
> Key: IGNITE-3512
> URL: https://issues.apache.org/jira/browse/IGNITE-3512
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Steps to reproduce:
> * Create a builder for a string type name, set field, put to cache
> * On another node, read this object, call ToBuilder, call Build
> Type name is not propagated with metadata, which leads to assertion error 
> (with -ea) or "Two binary types have duplicate type ID [typeId=949122880, 
> typeName1=Security, typeName2=null]]" error.
> Unit test:
> {code}
> [Test]
> public void Test()
> {
> using (var grid1 = 
> Ignition.Start(TestUtils.GetTestConfiguration()))
> using (var grid2 = Ignition.Start(new 
> IgniteConfiguration(TestUtils.GetTestConfiguration(false)) {GridName = 
> "grid2"}))
> {
> var cache1 = grid1.CreateCache int>("cache").WithKeepBinary();
> var obj1 = 
> grid1.GetBinary().GetBuilder("myType").SetField("myField", "val").Build();
> cache1[1] = obj1;
> var cache2 = grid2.GetCache int>("cache").WithKeepBinary();
> var obj2 = cache2[1];
> var val = obj2.GetField("myField");
> var obj2Ex = 
> grid2.GetBinary().GetBuilder(obj2).SetField("myField", val + 
> "_modified").Build();
> cache2[2] = obj2Ex;
> }
> }
> {code}
> Workaround is to register the type by name on start:
> {code}
> BinaryConfiguration = new BinaryConfiguration
> {
> Types = new[] {"myType"}
> }
> {code}



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

[jira] [Closed] (IGNITE-3505) BinaryObject keys can't be reused because of partition caching.

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-3505.
---

> BinaryObject keys can't be reused because of partition caching.
> ---
>
> Key: IGNITE-3505
> URL: https://issues.apache.org/jira/browse/IGNITE-3505
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: 3505.patch
>
>
> BinaryObject can't be reused as key between caches because it's
> actual implementation BinaryObjectImpl implements KeyCacheObject and
> due to the fact caches partition, which is not recalculated later.
> See 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition:
> {code}
> if (key instanceof KeyCacheObject && ((KeyCacheObject)key).partition() != -1)
> return ((KeyCacheObject)key).partition();
> {code}
> The issue can be reproduced with the following code:
> {code}
> public static void main(String[] args) throws IgniteException {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
> TcpDiscoveryVmIpFinder(true)));
> Ignite ignite = Ignition.start(cfg);
> CacheConfiguration cfg1 = new
> CacheConfiguration<>("Cache 1");
> cfg1.setCacheMode(CacheMode.PARTITIONED);
> cfg1.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> IgniteCache cache1 =
> ignite.getOrCreateCache(cfg1).withKeepBinary();
> CacheConfiguration cfg2 = new
> CacheConfiguration<>("Cache 2");
> cfg2.setCacheMode(CacheMode.REPLICATED);
> 
> cfg2.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> IgniteCache cache2 =
> ignite.getOrCreateCache(cfg2);
> BinaryObjectBuilder keyBuilder = ignite.binary().builder("keyType")
> .setField("F1", "V1").hashCode("V1".hashCode());
> BinaryObjectBuilder valBuilder = ignite.binary().builder("valueType")
> .setField("F2", "V2")
> .setField("F3", "V3");
> BinaryObject key = keyBuilder.build();
> BinaryObject val = valBuilder.build();
> cache1.put(key, val);
> cache2.put(key, val); // error
> System.out.println(cache1.get(key)); // error
> System.out.println(cache2.get(key)); 
> }
> {code}
> Corresponding user list thread: 
> http://apache-ignite-users.70518.x6.nabble.com/Adding-a-binary-object-to-two-caches-fails-with-FULL-SYNC-write-mode-configured-for-the-replicated-ce-tp6343p6366.html



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

[jira] [Commented] (IGNITE-3505) BinaryObject keys can't be reused because of partition caching.

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389342#comment-15389342
 ] 

Denis Magda commented on IGNITE-3505:
-

Thanks, merged the changes.

> BinaryObject keys can't be reused because of partition caching.
> ---
>
> Key: IGNITE-3505
> URL: https://issues.apache.org/jira/browse/IGNITE-3505
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: 3505.patch
>
>
> BinaryObject can't be reused as key between caches because it's
> actual implementation BinaryObjectImpl implements KeyCacheObject and
> due to the fact caches partition, which is not recalculated later.
> See 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition:
> {code}
> if (key instanceof KeyCacheObject && ((KeyCacheObject)key).partition() != -1)
> return ((KeyCacheObject)key).partition();
> {code}
> The issue can be reproduced with the following code:
> {code}
> public static void main(String[] args) throws IgniteException {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
> TcpDiscoveryVmIpFinder(true)));
> Ignite ignite = Ignition.start(cfg);
> CacheConfiguration cfg1 = new
> CacheConfiguration<>("Cache 1");
> cfg1.setCacheMode(CacheMode.PARTITIONED);
> cfg1.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> IgniteCache cache1 =
> ignite.getOrCreateCache(cfg1).withKeepBinary();
> CacheConfiguration cfg2 = new
> CacheConfiguration<>("Cache 2");
> cfg2.setCacheMode(CacheMode.REPLICATED);
> 
> cfg2.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> IgniteCache cache2 =
> ignite.getOrCreateCache(cfg2);
> BinaryObjectBuilder keyBuilder = ignite.binary().builder("keyType")
> .setField("F1", "V1").hashCode("V1".hashCode());
> BinaryObjectBuilder valBuilder = ignite.binary().builder("valueType")
> .setField("F2", "V2")
> .setField("F3", "V3");
> BinaryObject key = keyBuilder.build();
> BinaryObject val = valBuilder.build();
> cache1.put(key, val);
> cache2.put(key, val); // error
> System.out.println(cache1.get(key)); // error
> System.out.println(cache2.get(key)); 
> }
> {code}
> Corresponding user list thread: 
> http://apache-ignite-users.70518.x6.nabble.com/Adding-a-binary-object-to-two-caches-fails-with-FULL-SYNC-write-mode-configured-for-the-replicated-ce-tp6343p6366.html



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

[jira] [Closed] (IGNITE-3541) Visrocmd returns emty list of caches

[Sergey Kozlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Kozlov closed IGNITE-3541.
-

> Visrocmd returns emty list of caches
> 
>
> Key: IGNITE-3541
> URL: https://issues.apache.org/jira/browse/IGNITE-3541
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
> Fix For: 1.7
>
> Attachments: visor.bat, visor.xml
>
>
> 1. Start 3 nodes grid with attached config (copy in root fabric directory)
> {{bin/ignite.sh visor.xml}}
> 2. Execute visorcmd with attached batch file
> {{bin/ignitevisorcmd.sh visor.bat}}



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

[jira] [Resolved] (IGNITE-3541) Visrocmd returns emty list of caches

[Sergey Kozlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Kozlov resolved IGNITE-3541.
---
   Resolution: Fixed
Fix Version/s: 1.7

> Visrocmd returns emty list of caches
> 
>
> Key: IGNITE-3541
> URL: https://issues.apache.org/jira/browse/IGNITE-3541
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
> Fix For: 1.7
>
> Attachments: visor.bat, visor.xml
>
>
> 1. Start 3 nodes grid with attached config (copy in root fabric directory)
> {{bin/ignite.sh visor.xml}}
> 2. Execute visorcmd with attached batch file
> {{bin/ignitevisorcmd.sh visor.bat}}



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

[jira] [Updated] (IGNITE-2275) Hadoop: restore external code execution.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2275:

Labels: roadmap  (was: )

> Hadoop: restore external code execution.
> 
>
> Key: IGNITE-2275
> URL: https://issues.apache.org/jira/browse/IGNITE-2275
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: roadmap
>
> Several major problems with internal job execution were revealed:
> 1) Native code cannot run normally.
> 2) Excessive permgen allocations
> 3) We must use some dirty hacks to prevent classloader leaks (see mocked 
> classes in HadoopClassLoader).
> External execution must help us with it. 
> The problem is that it never worked properly. We must restore it and then 
> test very thoroughly.



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

[jira] [Updated] (IGNITE-2303) Allow PROXY mode execution in IGFS

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-2303:

Labels: roadmap  (was: )

> Allow PROXY mode execution in IGFS
> --
>
> Key: IGNITE-2303
> URL: https://issues.apache.org/jira/browse/IGNITE-2303
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: roadmap
>
> Currently we do not allow execution of Igfs commands on PROXY paths. Instead, 
> we assume that user must handle it on his own somehow.
> E.g., IgniteHadoopFileSystem creates its own instance of target FileSystem 
> and use it directly.
> We need to return to normal design when all commands can be executed on 
> IgfsImpl directly.



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

[jira] [Commented] (IGNITE-2294) Implement SQL DML (insert, update, delete) clauses.

[Alexander Paschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389259#comment-15389259
 ] 

Alexander Paschenko commented on IGNITE-2294:
-

Mailing list discussion on this issue is here: 
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-2294-implementation-details-td9968.html
Everyone that has anything to add is welcome to join it.

> Implement SQL DML (insert, update, delete) clauses.
> ---
>
> Key: IGNITE-2294
> URL: https://issues.apache.org/jira/browse/IGNITE-2294
> Project: Ignite
>  Issue Type: Wish
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
> Fix For: 1.7
>
>
> We need to add parsing for all the listed SQL commands and translate them 
> into respective cache operations (putIfAbstent, put, remove).



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

[jira] [Updated] (IGNITE-3541) Visrocmd returns emty list of caches

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-3541:
---
Assignee: Sergey Kozlov

> Visrocmd returns emty list of caches
> 
>
> Key: IGNITE-3541
> URL: https://issues.apache.org/jira/browse/IGNITE-3541
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
> Attachments: visor.bat, visor.xml
>
>
> 1. Start 3 nodes grid with attached config (copy in root fabric directory)
> {{bin/ignite.sh visor.xml}}
> 2. Execute visorcmd with attached batch file
> {{bin/ignitevisorcmd.sh visor.bat}}



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