[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-2310:
---

In addition, we should add the following methods:
{code}
void affinityRun(Collection cacheNames, int partId, IgniteRunnable job) 
throws IgniteException;
 R affinityCall(Collection cacheNames, int partId, IgniteCallable 
job) throws IgniteException;
{code}

> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity 
> node when a compute job is being sent to the node. The partition has to be 
> locked on the cache until the compute job is being executed. This will let to 
> execute queries safely (Scan or local SQL) over the data that is located 
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}} 
> and {{affinityRun}} methods that accept list of caches which partitions have 
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple 
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing 
> Organisation and Persons caches' names to the method to be sure that the 
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o 
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete, 
> the partition over which the query will be executed mustn't be moved to the 
> other node. Due to affinity collocation the partition number will be the same 
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}} 
> is executed.  
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently 
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only 
> one partition, but evict partitions after all partitions in all caches (with 
> same affinity function) on this node are locked for eviction. [~sboikov], can 
> you please comment? It seems this should work faster for closures and will 
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName, 
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with 
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions' 
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation 
> I think this will be negligible comparing to  job execution time
> - now caches are rebalanced completely independently and changing this be 
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity. 
> If user uses custom function should he implement 'equals'? For standard 
> affinity functions user can set backup filter, what do in this case? should 
> user implement 'equals' for filter? Even if affinity functions are the same 
> cache configuration can have node filter, so affinity mapping will be 
> different. 



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

[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-2310:
---

The API looks very strange. Why not just change the 1st parameter to a 
collection of strings, like so:
{code}
void affinityRun(Collection cacheNames, Object affKey, IgniteRunnable 
job) throws IgniteException;
 R affinityCall(Collection cacheNames, Object affKey, 
IgniteCallable job) throws IgniteException;
{code}

> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity 
> node when a compute job is being sent to the node. The partition has to be 
> locked on the cache until the compute job is being executed. This will let to 
> execute queries safely (Scan or local SQL) over the data that is located 
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}} 
> and {{affinityRun}} methods that accept list of caches which partitions have 
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple 
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing 
> Organisation and Persons caches' names to the method to be sure that the 
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o 
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete, 
> the partition over which the query will be executed mustn't be moved to the 
> other node. Due to affinity collocation the partition number will be the same 
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}} 
> is executed.  
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently 
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only 
> one partition, but evict partitions after all partitions in all caches (with 
> same affinity function) on this node are locked for eviction. [~sboikov], can 
> you please comment? It seems this should work faster for closures and will 
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName, 
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with 
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions' 
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation 
> I think this will be negligible comparing to  job execution time
> - now caches are rebalanced completely independently and changing this be 
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity. 
> If user uses custom function should he implement 'equals'? For standard 
> affinity functions user can set backup filter, what do in this case? should 
> user implement 'equals' for filter? Even if affinity functions are the same 
> cache configuration can have node filter, so affinity mapping will be 
> different. 



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

[jira] [Comment Edited] (IGNITE-3412) Client instance hangs on close

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-3412 at 7/8/16 8:41 PM:
-

[~ascherbakov], seems that I figured out why the client hung and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must treat {{InterruptedIOException}} differently. Not only 
{{SocketWriter}} but other similar parts of the platform must be fixed. I'm 
assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?


was (Author: dmagda):
[~ascherbakov], seems that I figured out why the client hung and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must threat {{InterruptedIOException}} differently. Not 
only {{SocketWriter}} but other similar parts of the platform must be fixed. 
I'm assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?

> Client instance hangs on close
> --
>
> Key: IGNITE-3412
> URL: https://issues.apache.org/jira/browse/IGNITE-3412
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
> Attachments: threadDump.txt
>
>
> In some cases calling close on Ignite client instance will lead to deadlock.
> The deadlock happens because of the following.
> Socket writer is waiting for new messages.
> {code}
> "tcp-client-disco-sock-writer-#2%null%" #100 prio=6 os_prio=0 
> tid=0x5fad2800 nid=0x13bc in Object.wait() [0x67d0e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1051)
>   - locked <0x863da2f8> (a java.lang.Object)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The closing process is hanging because TcpDiscoverySPI waits while this 
> writer is terminated
> {code}
> "Thread-6" #29 prio=6 os_prio=0 tid=0x5a74 nid=0x17e8 in 
> Object.wait() [0x6077e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0x863da010> (a 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4476)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:295)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:1905)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:325)
>

[jira] [Assigned] (IGNITE-3412) Client instance hangs on close

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-3412:
---

Assignee: Denis Magda  (was: Alexei Scherbakov)

> Client instance hangs on close
> --
>
> Key: IGNITE-3412
> URL: https://issues.apache.org/jira/browse/IGNITE-3412
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: threadDump.txt
>
>
> In some cases calling close on Ignite client instance will lead to deadlock.
> The deadlock happens because of the following.
> Socket writer is waiting for new messages.
> {code}
> "tcp-client-disco-sock-writer-#2%null%" #100 prio=6 os_prio=0 
> tid=0x5fad2800 nid=0x13bc in Object.wait() [0x67d0e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1051)
>   - locked <0x863da2f8> (a java.lang.Object)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The closing process is hanging because TcpDiscoverySPI waits while this 
> writer is terminated
> {code}
> "Thread-6" #29 prio=6 os_prio=0 tid=0x5a74 nid=0x17e8 in 
> Object.wait() [0x6077e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0x863da010> (a 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4476)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:295)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:1905)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:325)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1336)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1940)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1812)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2248)
>   - locked <0x858e77a8> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2211)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:322)
>   at org.apache.ignite.Ignition.stop(Ignition.java:224)
>   at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:2921)
>   at ru.sbrf.ggcod.loader.job.MainLoader.run(MainLoader.java:123)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> There is some raise that led to the situation when the writer is hanging on 
> {{Object.wait}} method ignoring interrupted flag that was set at some point 
> of time.
> The full thread dump is attached.



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

[jira] [Comment Edited] (IGNITE-3412) Client instance hangs on close

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-3412 at 7/8/16 8:41 PM:
-

[~ascherbakov], seems that I figured out why the client hung and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must treat {{InterruptedIOException}} differently. Not only 
{{SocketWriter}} but other similar parts of the platform must be fixed. I'm 
assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at your hands? I remember you were telling that 
before {{SocketWriter}} moved to the hanging state it threw some kind of IO 
Exception. What was that?


was (Author: dmagda):
[~ascherbakov], seems that I figured out why the client hung and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must treat {{InterruptedIOException}} differently. Not only 
{{SocketWriter}} but other similar parts of the platform must be fixed. I'm 
assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?

> Client instance hangs on close
> --
>
> Key: IGNITE-3412
> URL: https://issues.apache.org/jira/browse/IGNITE-3412
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
> Attachments: threadDump.txt
>
>
> In some cases calling close on Ignite client instance will lead to deadlock.
> The deadlock happens because of the following.
> Socket writer is waiting for new messages.
> {code}
> "tcp-client-disco-sock-writer-#2%null%" #100 prio=6 os_prio=0 
> tid=0x5fad2800 nid=0x13bc in Object.wait() [0x67d0e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1051)
>   - locked <0x863da2f8> (a java.lang.Object)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The closing process is hanging because TcpDiscoverySPI waits while this 
> writer is terminated
> {code}
> "Thread-6" #29 prio=6 os_prio=0 tid=0x5a74 nid=0x17e8 in 
> Object.wait() [0x6077e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0x863da010> (a 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4476)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:295)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:1905)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:325)

[jira] [Commented] (IGNITE-3412) Client instance hangs on close

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3412:
-

[~ascherbakov], seems that I figured out why the client hangs and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must threat {{InterruptedIOException}} differently. Not 
only {{SocketWriter}} but other similar parts of the platform must be fixed. 
I'm assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?

> Client instance hangs on close
> --
>
> Key: IGNITE-3412
> URL: https://issues.apache.org/jira/browse/IGNITE-3412
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
> Attachments: threadDump.txt
>
>
> In some cases calling close on Ignite client instance will lead to deadlock.
> The deadlock happens because of the following.
> Socket writer is waiting for new messages.
> {code}
> "tcp-client-disco-sock-writer-#2%null%" #100 prio=6 os_prio=0 
> tid=0x5fad2800 nid=0x13bc in Object.wait() [0x67d0e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1051)
>   - locked <0x863da2f8> (a java.lang.Object)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The closing process is hanging because TcpDiscoverySPI waits while this 
> writer is terminated
> {code}
> "Thread-6" #29 prio=6 os_prio=0 tid=0x5a74 nid=0x17e8 in 
> Object.wait() [0x6077e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0x863da010> (a 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4476)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:295)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:1905)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:325)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1336)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1940)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1812)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2248)
>   - locked <0x858e77a8> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2211)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:322)
>   at org.apache.ignite.Ignition.stop(Ignition.java:224)
>   at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:2921)
>   at ru.sbrf.ggcod.loader.job.MainLoader.run(MainLoader.java:123)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> There is some raise that led to the situation when the writer is hanging on 
> {{Object.wait}} method ignoring interrupted flag that was set at some point 
> of time.
> The full thread dump is attached.



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

[jira] [Comment Edited] (IGNITE-3412) Client instance hangs on close

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-3412 at 7/8/16 8:40 PM:
-

[~ascherbakov], seems that I figured out why the client hung and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must threat {{InterruptedIOException}} differently. Not 
only {{SocketWriter}} but other similar parts of the platform must be fixed. 
I'm assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?


was (Author: dmagda):
[~ascherbakov], seems that I figured out why the client hangs and the 
interrupted flag is ignored. The reason is that we ignore 
{{InterruptedIOException}} in the loop of {{SocketWriter}}. Basically the 
following can happen:

1) {{SocketWriter}} is writing a chunk of data using {{spi.writeToSocket(sock, 
msg, socketTimeout)}};
2) {{Ignite}} is being closed and {{interrupt}} is executed for 
{{SocketWriter}} thread;
3) underlying I/O code that is executed by {{spi.writeToSocket(sock, msg, 
socketTimeout)}} sees that the thread has been interrupted and throws 
{{InterruptedIOExceptio}} and not {{InterruptedException}}!!! When 
{{InterruptedIOException}} is thrown the interrupted flag is cleared; 
4) since {{InterruptedIOException}} is just a kind of {{IOException}} then 
{{SocketWriter}} catches this exception, closes the socket, checks that the 
Thread is not interrupted and hangs at {{mux.wait()}}.

To fix the issue we must threat {{InterruptedIOException}} differently. Not 
only {{SocketWriter}} but other similar parts of the platform must be fixed. 
I'm assigning the ticket on myself and will finalize it in the nearest time.

BTW, do you have the logs at hands? I remember you were telling that before 
{{SocketWriter}} moved to the hanging state it threw some kind of IO Exception. 
What was that?

> Client instance hangs on close
> --
>
> Key: IGNITE-3412
> URL: https://issues.apache.org/jira/browse/IGNITE-3412
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
> Attachments: threadDump.txt
>
>
> In some cases calling close on Ignite client instance will lead to deadlock.
> The deadlock happens because of the following.
> Socket writer is waiting for new messages.
> {code}
> "tcp-client-disco-sock-writer-#2%null%" #100 prio=6 os_prio=0 
> tid=0x5fad2800 nid=0x13bc in Object.wait() [0x67d0e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1051)
>   - locked <0x863da2f8> (a java.lang.Object)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The closing process is hanging because TcpDiscoverySPI waits while this 
> writer is terminated
> {code}
> "Thread-6" #29 prio=6 os_prio=0 tid=0x5a74 nid=0x17e8 in 
> Object.wait() [0x6077e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Thread.join(Thread.java:1245)
>   - locked <0x863da010> (a 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter)
>   at java.lang.Thread.join(Thread.java:1319)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4476)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:295)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:1905)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:325)
>  

[jira] [Created] (IGNITE-3457) Active Store

[Alexandre Boudnik (JIRA)]

Alexandre Boudnik created IGNITE-3457:
-

 Summary: Active Store
 Key: IGNITE-3457
 URL: https://issues.apache.org/jira/browse/IGNITE-3457
 Project: Ignite
  Issue Type: New Feature
  Components: general
Reporter: Alexandre Boudnik
Assignee: Alexandre Boudnik


To address missing features, such as backup/restore, snapshot, replication, and 
continues export



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

[jira] [Commented] (IGNITE-3314) Implement Serializable in org.apache.ignite.cache.store.cassandra.datasource.DataSource

[Bakul Ghughal (JIRA)]

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

Bakul Ghughal commented on IGNITE-3314:
---

Is this item prioritized and being worked on? We started POC with Cassandra 
cache store but can not use it yet because all our config is in code. Thanks.

> Implement Serializable in 
> org.apache.ignite.cache.store.cassandra.datasource.DataSource
> ---
>
> Key: IGNITE-3314
> URL: https://issues.apache.org/jira/browse/IGNITE-3314
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Igor Rudyak
>Assignee: Igor Rudyak
>Priority: Minor
> Fix For: 1.6
>
>
> Current implementation of 
> org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource doesn't 
> implement Serializable, thus for distributed Ignite clusters, 
> CassandraCacheStoreFactory could only be setup through Spring XML file, but 
> not from code. 
> New version of 
> org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource should  
> implement Serializable



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

[jira] [Comment Edited] (IGNITE-3055) IgniteDataStreamer can't be timed out

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov edited comment on IGNITE-3055 at 7/8/16 7:24 PM:
---

Thank [~dmagda]

Added pull reuest: https://github.com/apache/ignite/pull/864

I not noticed in the comments.
I think it redundant about 1 and 2.
1 - activeFuts will by done alvays when buffer future has done (becasu it done 
on listener on future of buffer)
2 - busyLock must by using in try - finaly block. Put time waiting on busyLock 
only will hid an other exception.
Unit test I will add in nearest time (about 3).


was (Author: v.pyatkov):
Thank [~dmagda]

I not noticed in the comments.
I think it redundant about 1 and 2.
1 - activeFuts will by done alvays when buffer future has done (becasu it done 
on listener on future of buffer)
2 - busyLock must by using in try - finaly block. Put time waiting on busyLock 
only will hid an other exception.
Unit test I will add in nearest time (about 3).

> IgniteDataStreamer can't be timed out
> -
>
> Key: IGNITE-3055
> URL: https://issues.apache.org/jira/browse/IGNITE-3055
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Critical
>  Labels: community, customer, important
> Fix For: 1.7
>
>
> In current implementation there is no way to timeout the data streamer. 
> Specifically, {{addData()}} can hang on the parallel operations semaphore and 
> {{close()}} can infinitely wait on one of the futures to complete.
> We should introduce the configurable timeout and fail any data streamer 
> operation if it's exceeded.



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

[jira] [Commented] (IGNITE-3055) IgniteDataStreamer can't be timed out

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov commented on IGNITE-3055:
---

Thank [~dmagda]

I not noticed in the comments.
I think it redundant about 1 and 2.
1 - activeFuts will by done alvays when buffer future has done (becasu it done 
on listener on future of buffer)
2 - busyLock must by using in try - finaly block. Put time waiting on busyLock 
only will hid an other exception.
Unit test I will add in nearest time (about 3).

> IgniteDataStreamer can't be timed out
> -
>
> Key: IGNITE-3055
> URL: https://issues.apache.org/jira/browse/IGNITE-3055
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Critical
>  Labels: community, customer, important
> Fix For: 1.7
>
>
> In current implementation there is no way to timeout the data streamer. 
> Specifically, {{addData()}} can hang on the parallel operations semaphore and 
> {{close()}} can infinitely wait on one of the futures to complete.
> We should introduce the configurable timeout and fail any data streamer 
> operation if it's exceeded.



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

[jira] [Commented] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3455:
-

Ok, It seems C++ and Java {{DFId}} types have different type ids. This seems to 
be a cause - when I have changed C++ method 
{{BinaryType::GetTypeId()}} to return the same type id it 
all began to work. I'll examine this issue further.

> Entry placed on C++ side is not found on Java side
> --
>
> Key: IGNITE-3455
> URL: https://issues.apache.org/jira/browse/IGNITE-3455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Blocker
> Attachments: cpp.zip, java.zip
>
>
> If a custom key is used for cache values then the following scenario doesn't 
> work:
> - value is placed on C++ side;
> - value is read on Java side (value is not found here).
> Reverse direction is not workable as well.
> HashCode is implemented properly in C++ and Java.
> Fast debugging showed that a partition and primary node is calculated 
> properly. Looks like that there is a serialization related issue that leads 
> to the situation when "equals" fails during an object lookup.



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

[jira] [Commented] (IGNITE-3456) Make sure EntryProcessor is always running on a OWNING partition

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-3456:
--

Linking the late affinity assignment ticket.

> Make sure EntryProcessor is always running on a OWNING partition
> 
>
> Key: IGNITE-3456
> URL: https://issues.apache.org/jira/browse/IGNITE-3456
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>
> Let's say I need to maintain some sort of an aggregate function over a 
> partition. This aggregate is maintained using an entry processor, and before 
> an update this entry processor queries this local aggregate.
> If an entry processor is applied on a partition with a MOVING state, the 
> state of the local aggregate is not valid because not all data has been 
> preloaded. If entry processor is applied on an OWNING partition, the result 
> is guaranteed to be correct.
> Given that we have implemented late affinity assignment when a new node is 
> assigned primary only when rebalancing is finished, this should be already 
> maintained. We just need to add tests verifying the partition state in 
> EntryProcessor.



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

[jira] [Created] (IGNITE-3456) Make sure EntryProcessor is always running on a OWNING partition

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-3456:


 Summary: Make sure EntryProcessor is always running on a OWNING 
partition
 Key: IGNITE-3456
 URL: https://issues.apache.org/jira/browse/IGNITE-3456
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Alexey Goncharuk


Let's say I need to maintain some sort of an aggregate function over a 
partition. This aggregate is maintained using an entry processor, and before an 
update this entry processor queries this local aggregate.

If an entry processor is applied on a partition with a MOVING state, the state 
of the local aggregate is not valid because not all data has been preloaded. If 
entry processor is applied on an OWNING partition, the result is guaranteed to 
be correct.

Given that we have implemented late affinity assignment when a new node is 
assigned primary only when rebalancing is finished, this should be already 
maintained. We just need to add tests verifying the partition state in 
EntryProcessor.



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

[jira] [Closed] (IGNITE-3227) IgniteCache: add method to calculate size per partition

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk closed IGNITE-3227.


> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Alexey Goncharuk
>  Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following 
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws 
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}



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

[jira] [Updated] (IGNITE-3440) Ignite Services: ServiceTopologyCallable is executed before system cache is started

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3440:

Attachment: ignite-3440.diff

> Ignite Services: ServiceTopologyCallable is executed before system cache is 
> started
> ---
>
> Key: IGNITE-3440
> URL: https://issues.apache.org/jira/browse/IGNITE-3440
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: ignite-3440.diff
>
>
> In rare cases it's possible to get the following exception
> {code}
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-0] 2016-07-01 
> 16:03:54,120 22971 INFO  
> [com.workday.fabric.ignite.management.QuorumEventDispatcher] Storage count 
> changed - oldvalue: 3 - newvalue: 4 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] 2016-07-01 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] 2016-07-01 
> 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] class org.apache.ignite.IgniteException: null
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] class 
> org.apache.ignite.IgniteException: null
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6484)
> [16:03:54] :   

[jira] [Updated] (IGNITE-3440) Ignite Services: ServiceTopologyCallable is executed before system cache is started

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3440:

Attachment: (was: ignite-3440.diff)

> Ignite Services: ServiceTopologyCallable is executed before system cache is 
> started
> ---
>
> Key: IGNITE-3440
> URL: https://issues.apache.org/jira/browse/IGNITE-3440
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: ignite-3440.diff
>
>
> In rare cases it's possible to get the following exception
> {code}
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-0] 2016-07-01 
> 16:03:54,120 22971 INFO  
> [com.workday.fabric.ignite.management.QuorumEventDispatcher] Storage count 
> changed - oldvalue: 3 - newvalue: 4 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] 2016-07-01 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] 2016-07-01 
> 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] class org.apache.ignite.IgniteException: null
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] class 
> org.apache.ignite.IgniteException: null
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6484)
> [16:03:54] :   

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

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-3343:
-

We have difficulty there: if accordingly to the current fix plan we don't store 
access/modification time in DUAL modes, we have to write it to the secondary 
file system in response to 
org.apache.ignite.internal.processors.igfs.IgfsImpl#setTimes call. But 
org.apache.ignite.igfs.secondary.IgfsSecondaryFileSystem does not provide a 
method to set access/modification times to a secondary Fs file. So, we either 
should provide such method, or cache the modification/access times in IgfsImpl 
instance in some cases.

> 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: Improvement
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> 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] [Assigned] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Igor Sapego (JIRA)]

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

Igor Sapego reassigned IGNITE-3455:
---

Assignee: Igor Sapego  (was: Denis Magda)

> Entry placed on C++ side is not found on Java side
> --
>
> Key: IGNITE-3455
> URL: https://issues.apache.org/jira/browse/IGNITE-3455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Blocker
> Attachments: cpp.zip, java.zip
>
>
> If a custom key is used for cache values then the following scenario doesn't 
> work:
> - value is placed on C++ side;
> - value is read on Java side (value is not found here).
> Reverse direction is not workable as well.
> HashCode is implemented properly in C++ and Java.
> Fast debugging showed that a partition and primary node is calculated 
> properly. Looks like that there is a serialization related issue that leads 
> to the situation when "equals" fails during an object lookup.



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

[jira] [Updated] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3455:

Attachment: cpp.zip

Added C++ files.

> Entry placed on C++ side is not found on Java side
> --
>
> Key: IGNITE-3455
> URL: https://issues.apache.org/jira/browse/IGNITE-3455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Attachments: cpp.zip, java.zip
>
>
> If a custom key is used for cache values then the following scenario doesn't 
> work:
> - value is placed on C++ side;
> - value is read on Java side (value is not found here).
> Reverse direction is not workable as well.
> HashCode is implemented properly in C++ and Java.
> Fast debugging showed that a partition and primary node is calculated 
> properly. Looks like that there is a serialization related issue that leads 
> to the situation when "equals" fails during an object lookup.



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

[jira] [Commented] (IGNITE-3440) Ignite Services: ServiceTopologyCallable is executed before system cache is started

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3440:
-

[~vkulichenko], it would be perfect if you find the time for review because I'm 
modifying the code that was originally written by you.

> Ignite Services: ServiceTopologyCallable is executed before system cache is 
> started
> ---
>
> Key: IGNITE-3440
> URL: https://issues.apache.org/jira/browse/IGNITE-3440
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: ignite-3440.diff, ignite-3440.diff
>
>
> In rare cases it's possible to get the following exception
> {code}
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-0] 2016-07-01 
> 16:03:54,120 22971 INFO  
> [com.workday.fabric.ignite.management.QuorumEventDispatcher] Storage count 
> changed - oldvalue: 3 - newvalue: 4 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] 2016-07-01 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] 2016-07-01 
> 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] class org.apache.ignite.IgniteException: null
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] class 
> org.apache.ignite.IgniteException: null
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [testQuorumEvents] 

[jira] [Updated] (IGNITE-3440) Ignite Services: ServiceTopologyCallable is executed before system cache is started

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3440:

Attachment: ignite-3440.diff

> Ignite Services: ServiceTopologyCallable is executed before system cache is 
> started
> ---
>
> Key: IGNITE-3440
> URL: https://issues.apache.org/jira/browse/IGNITE-3440
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: ignite-3440.diff, ignite-3440.diff
>
>
> In rare cases it's possible to get the following exception
> {code}
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-0] 2016-07-01 
> 16:03:54,120 22971 INFO  
> [com.workday.fabric.ignite.management.QuorumEventDispatcher] Storage count 
> changed - oldvalue: 3 - newvalue: 4 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] 2016-07-01 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] 2016-07-01 
> 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] class org.apache.ignite.IgniteException: null
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] class 
> org.apache.ignite.IgniteException: null
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6484)
> [16:03:54] :  

[jira] [Commented] (IGNITE-3440) Ignite Services: ServiceTopologyCallable is executed before system cache is started

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3440:
-

[~agoncharuk], good point!

I've reimplemented the fix using continuation API. Also I decided to use a 
timeout avoiding indefinite waits. Please see updated patch file.

The pull-request has been created (https://github.com/apache/ignite/pull/862) 
as well but it contains much more changes. Checking on TC.

> Ignite Services: ServiceTopologyCallable is executed before system cache is 
> started
> ---
>
> Key: IGNITE-3440
> URL: https://issues.apache.org/jira/browse/IGNITE-3440
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.7
>
> Attachments: ignite-3440.diff
>
>
> In rare cases it's possible to get the following exception
> {code}
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-0] 2016-07-01 
> 16:03:54,120 22971 INFO  
> [com.workday.fabric.ignite.management.QuorumEventDispatcher] Storage count 
> changed - oldvalue: 3 - newvalue: 4 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] 2016-07-01 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] 2016-07-01 
> 16:03:54,242 1492  ERROR 
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to execute 
> job [jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  dep=LocalDeployment [super=GridDeployment [ts=1467389033352, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, 
> clsLdrId=989b337a551-b26cd969-888f-4580-a2cb-ad10019da322, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.service.GridServiceProcessor$ServiceTopologyCallable,
>  sesId=9c1b337a551-33dedfed-ef93-405c-af02-cd37d7426df9, 
> startTime=1467389034118, endTime=9223372036854775807, 
> taskNodeId=33dedfed-ef93-405c-af02-cd37d7426df9, 
> clsLdr=sun.misc.Launcher$AppClassLoader@14dad5dc, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=33dedfed-ef93-405c-af02-cd37d7426df9, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1467389034228, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=ac1b337a551-b26cd969-888f-4580-a2cb-ad10019da322]] 
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7] class org.apache.ignite.IgniteException: null
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7] class 
> org.apache.ignite.IgniteException: null
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2007)
> [16:03:54] :   [testQuorumEvents] [Test Output]
> [FabricRunner-7]  at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> [16:03:54] :   [:fabric-tests:test] [FabricRunner-7]  

[jira] [Commented] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3455:
-

[~isapego], please attach C++ part of the code.

> Entry placed on C++ side is not found on Java side
> --
>
> Key: IGNITE-3455
> URL: https://issues.apache.org/jira/browse/IGNITE-3455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Attachments: java.zip
>
>
> If a custom key is used for cache values then the following scenario doesn't 
> work:
> - value is placed on C++ side;
> - value is read on Java side (value is not found here).
> Reverse direction is not workable as well.
> HashCode is implemented properly in C++ and Java.
> Fast debugging showed that a partition and primary node is calculated 
> properly. Looks like that there is a serialization related issue that leads 
> to the situation when "equals" fails during an object lookup.



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

[jira] [Updated] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3455:

Attachment: java.zip

> Entry placed on C++ side is not found on Java side
> --
>
> Key: IGNITE-3455
> URL: https://issues.apache.org/jira/browse/IGNITE-3455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Attachments: java.zip
>
>
> If a custom key is used for cache values then the following scenario doesn't 
> work:
> - value is placed on C++ side;
> - value is read on Java side (value is not found here).
> Reverse direction is not workable as well.
> HashCode is implemented properly in C++ and Java.
> Fast debugging showed that a partition and primary node is calculated 
> properly. Looks like that there is a serialization related issue that leads 
> to the situation when "equals" fails during an object lookup.



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

[jira] [Created] (IGNITE-3455) Entry placed on C++ side is not found on Java side

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3455:
---

 Summary: Entry placed on C++ side is not found on Java side
 Key: IGNITE-3455
 URL: https://issues.apache.org/jira/browse/IGNITE-3455
 Project: Ignite
  Issue Type: Bug
  Components: cache, platforms
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Blocker


If a custom key is used for cache values then the following scenario doesn't 
work:
- value is placed on C++ side;
- value is read on Java side (value is not found here).

Reverse direction is not workable as well.

HashCode is implemented properly in C++ and Java.

Fast debugging showed that a partition and primary node is calculated properly. 
Looks like that there is a serialization related issue that leads to the 
situation when "equals" fails during an object lookup.



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

[jira] [Commented] (IGNITE-3414) Hadoop: Optimize map-reduce job planning.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-3414:
-

General comments regarding the tasks distribution algorithm.

1) Not quite clear, why the idea of "threshold migration" is used for reducers. 
Namely, why the idea of weighted load calculation does not seem to be enough in 
this case.
Also not quite clear , why logic "add new load to the least loaded machine" is 
used, while logic "calculate resultant load for all possible load assignment 
possibilities, and chose smallest load among them" seems to be more correct. 
(We use the latter logic when planning the mapper tasks).

2) In general, Map-Reduce algorithm suggests that each reducer may require 
results of all the Mappers. This way for reducer assignments we should not 
consider splits affinity. Instead, we should consider Map tasks assignments: 
e.g. if 3 of 10 Map tasks assigned to node X, 30% of reducer input data reside 
on node X, and this is true for *any* reducer.
Taking this approach, we could simplify reducer assignment algorithm.

3) May be it's worth to think about 3 grades of data transfer load: (1) data 
transferred between machines, (2) data transferred from one node to another on 
the same machine , (3) data not transferred (produced and used on the same 
node). Also the load calculation may become much more accurate if taken 
proportionally to the summary data length.

> Hadoop: Optimize map-reduce job planning.
> -
>
> Key: IGNITE-3414
> URL: https://issues.apache.org/jira/browse/IGNITE-3414
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently Hadoop module has inefficient map-reduce planning engine. In 
> particular, it assigns tasks only to affinity nodes. It could lead to 
> situation when very huge tasks is processed by a single cluster node, while 
> other cluster nodes are idle. 
> We should implement configurable map-reduce planner which will be able to 
> utilize the whole cluster.



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

[jira] [Updated] (IGNITE-3454) Used Thread.getContextClassLoader() classloader for P2P

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3454:
-
Description: 
{{GridClassLoaderCache#detectClassLoader}} tries to load class by 
{{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
to errors in cache operations:
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
incompatible class loaders for cache [class1=[C, 
class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.prepareObject(GridCacheMessage.java:214)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.marshalInvokeArguments(GridCacheMessage.java:430)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.prepareMarshal(GridNearAtomicUpdateRequest.java:607)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:620)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:642)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:803)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:469)
... 44 more
{noformat}

Test which reproduced the issue in attachment and see on 
{{GridCacheDeploymentManager#registerClass(java.lang.Class, 
java.lang.ClassLoader)}}.

  was:
{{GridClassLoaderCache#detectClassLoader}} tries to load class by 
{{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
to errors in cache operations:
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
incompatible class loaders for cache [class1=[C, 
class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.prepareObject(GridCacheMessage.java:214)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.marshalInvokeArguments(GridCacheMessage.java:430)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.prepareMarshal(GridNearAtomicUpdateRequest.java:607)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:620)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:642)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:803)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:469)
... 44 more
{noformat}

Test which reproduced the issue in attachment and see on 
{{GridCacheDeploymentManager#registerClass(java.lang.Class, 
java.lang.ClassLoader)}}.


> Used Thread.getContextClassLoader() classloader for P2P
> ---
>
> Key: IGNITE-3454
> URL: https://issues.apache.org/jira/browse/IGNITE-3454
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Fix For: 1.7
>
> Attachments: DeployTest.patch
>
>
> {{GridClassLoaderCache#detectClassLoader}} tries to load class by 
> {{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
> to errors in cache operations:
> {noformat}
> Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
> incompatible class loaders for cache [class1=[C, 
> class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
> at 
> 

[jira] [Updated] (IGNITE-3454) Used Thread.getContextClassLoader() classloader for P2P

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-3454:
-
Attachment: DeployTest.patch

> Used Thread.getContextClassLoader() classloader for P2P
> ---
>
> Key: IGNITE-3454
> URL: https://issues.apache.org/jira/browse/IGNITE-3454
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Fix For: 1.7
>
> Attachments: DeployTest.patch
>
>
> {{GridClassLoaderCache#detectClassLoader}} tries to load class by 
> {{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
> to errors in cache operations:
> {noformat}
> Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
> incompatible class loaders for cache [class1=[C, 
> class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMessage.prepareObject(GridCacheMessage.java:214)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMessage.marshalInvokeArguments(GridCacheMessage.java:430)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.prepareMarshal(GridNearAtomicUpdateRequest.java:607)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:620)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:642)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:803)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:469)
> ... 44 more
> {noformat}
> Test which reproduced the issue in attachment and see on 
> {{GridCacheDeploymentManager#registerClass(java.lang.Class, 
> java.lang.ClassLoader)}}.



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

[jira] [Created] (IGNITE-3454) Used Thread.getContextClassLoader() classloader for P2P

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3454:


 Summary: Used Thread.getContextClassLoader() classloader for P2P
 Key: IGNITE-3454
 URL: https://issues.apache.org/jira/browse/IGNITE-3454
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Nikolay Tikhonov
 Fix For: 1.7


{{GridClassLoaderCache#detectClassLoader}} tries to load class by 
{{Thread.getContextClassLoader()}} when it possible. In some cases it to lead 
to errors in cache operations:
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Encountered 
incompatible class loaders for cache [class1=[C, 
class2=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap]
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:666)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.registerClass(GridCacheDeploymentManager.java:611)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.prepareObject(GridCacheMessage.java:214)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.marshalInvokeArguments(GridCacheMessage.java:430)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.prepareMarshal(GridNearAtomicUpdateRequest.java:607)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:620)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:642)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:803)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:469)
... 44 more
{noformat}

Test which reproduced the issue in attachment and see on 
{{GridCacheDeploymentManager#registerClass(java.lang.Class, 
java.lang.ClassLoader)}}.



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

[jira] [Updated] (IGNITE-3448) Wrong count returned by count distinct and similar queries.

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-3448:
-
Component/s: SQL

> Wrong count returned by count distinct and similar queries.
> ---
>
> Key: IGNITE-3448
> URL: https://issues.apache.org/jira/browse/IGNITE-3448
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Alexei Scherbakov
>
> Partitioned cache is deployed on 3 nodes.
> The code below outputs incorrect counts: 
> 14
> 14
> {code}
>IgniteCache cache = grid(0).cache(null);
> cache.put(0, new Value("v1"));
> cache.put(3, new Value("v1"));
> cache.put(5, new Value("v1"));
> cache.put(9, new Value("v1"));
> cache.put(1, new Value("v3"));
> cache.put(15, new Value("v3"));
> cache.put(8, new Value("v3"));
> cache.put(2, new Value("v5"));
> cache.put(12, new Value("v5"));
> cache.put(4, new Value("v2"));
> cache.put(6, new Value("v2"));
> cache.put(7, new Value("v6"));
> cache.put(10, new Value("v7"));
> cache.put(11, new Value("v8"));
> cache.put(13, new Value("v4"));
> cache.put(14, new Value("v4"));
> QueryCursor qry = cache.query(new SqlFieldsQuery("select 
> count(distinct str) from Value"));
> for (List objects : qry)
> System.out.println(objects.get(0));
> qry = cache.query(new SqlFieldsQuery("select count(*) from (select 1 
> from Value group by str)"));
> for (List objects : qry)
> System.out.println(objects.get(0));
>
> {code}



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

[jira] [Updated] (IGNITE-3453) Query engine picks incorrect index in certain configurations.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-3453:
--
Attachment: Example.java

> Query engine picks incorrect index in certain configurations.
> -
>
> Key: IGNITE-3453
> URL: https://issues.apache.org/jira/browse/IGNITE-3453
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexei Scherbakov
> Attachments: Example.java
>
>
> Index selection depends on index name ordering, not the argument type.
> Index 1 (name idx_1):
> countryId:Integer, regionId:Integer, cityId:Integer
> Index 2 (name idx_0):
> countryId:Integer, regionId:Integer, nation:String
> For query:
> select id, countryId, cityId from Person where countryId=? and regionId=? and 
> cityId=? params 1,1,1
> the index 2 is picked incorrectly and only two first fields are used.
> See full reproducer in the attachment.



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

[jira] [Created] (IGNITE-3453) Query engine picks incorrect index in certain configurations.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-3453:
-

 Summary: Query engine picks incorrect index in certain 
configurations.
 Key: IGNITE-3453
 URL: https://issues.apache.org/jira/browse/IGNITE-3453
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
 Attachments: Example.java

Index selection depends on index name ordering, not the argument type.

Index 1 (name idx_1):
countryId:Integer, regionId:Integer, cityId:Integer

Index 2 (name idx_0):
countryId:Integer, regionId:Integer, nation:String

For query:
select id, countryId, cityId from Person where countryId=? and regionId=? and 
cityId=? params 1,1,1

the index 2 is picked incorrectly and only two first fields are used.

See full reproducer in the attachment.



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

[jira] [Updated] (IGNITE-3452) Web console: We need to add a validation that pool size has value greater the zero

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-3452:
---
Issue Type: Sub-task  (was: Bug)
Parent: IGNITE-2047

> Web console: We need to add a validation that pool size has value greater the 
> zero
> --
>
> Key: IGNITE-3452
> URL: https://issues.apache.org/jira/browse/IGNITE-3452
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Priority: Trivial
>
> Currently I was able to enter MarshallerPoolSize=0 and got the exception on 
> node start
> {code}
> java.lang.IllegalArgumentException
> at 
> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1310)
> at 
> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1233)
> at 
> org.apache.ignite.thread.IgniteThreadPoolExecutor.(IgniteThreadPoolExecutor.java:185)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1720)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:964)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:850)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:749)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:619)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Failed to start grid: null
> {code}



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

[jira] [Updated] (IGNITE-3452) Web console: We need to add a validation that pool size has value greater the zero

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-3452:
---
Summary: Web console: We need to add a validation that pool size has value 
greater the zero  (was: We need to add a validation that pool size has value 
greater the zero)

> Web console: We need to add a validation that pool size has value greater the 
> zero
> --
>
> Key: IGNITE-3452
> URL: https://issues.apache.org/jira/browse/IGNITE-3452
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Trivial
>
> Currently I was able to enter MarshallerPoolSize=0 and got the exception on 
> node start
> {code}
> java.lang.IllegalArgumentException
> at 
> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1310)
> at 
> java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1233)
> at 
> org.apache.ignite.thread.IgniteThreadPoolExecutor.(IgniteThreadPoolExecutor.java:185)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1720)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:964)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:850)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:749)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:619)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Failed to start grid: null
> {code}



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

[jira] [Created] (IGNITE-3452) We need to add a validation that pool size has value greater the zero

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-3452:
--

 Summary: We need to add a validation that pool size has value 
greater the zero
 Key: IGNITE-3452
 URL: https://issues.apache.org/jira/browse/IGNITE-3452
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Priority: Trivial


Currently I was able to enter MarshallerPoolSize=0 and got the exception on 
node start
{code}
java.lang.IllegalArgumentException
at 
java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1310)
at 
java.util.concurrent.ThreadPoolExecutor.(ThreadPoolExecutor.java:1233)
at 
org.apache.ignite.thread.IgniteThreadPoolExecutor.(IgniteThreadPoolExecutor.java:185)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1720)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:964)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:850)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:749)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:619)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:347)
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Failed to start grid: null
{code}



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

[jira] [Updated] (IGNITE-3425) Missed options in SQL editor.

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-3425:
---
Assignee: Vasiliy Sisko  (was: Andrey Novikov)

> Missed options in SQL editor.
> -
>
> Key: IGNITE-3425
> URL: https://issues.apache.org/jira/browse/IGNITE-3425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> On opening of SQL notebook in log showed messages for every paragraph:
> common.0bf89e8….js:12 misspelled option "enableSnippets"
> common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
> common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"
> Also does not work code completion.



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

[jira] [Assigned] (IGNITE-3138) IgniteDataStreamer: failures are not shown on the streaming side

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov reassigned IGNITE-3138:
-

Assignee: Vladislav Pyatkov  (was: Alexei Scherbakov)

> IgniteDataStreamer: failures are not shown on the streaming side
> 
>
> Key: IGNITE-3138
> URL: https://issues.apache.org/jira/browse/IGNITE-3138
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
>
> If an exception happens during the streaming, the side that streams the data 
> won't printed out anything in its logs even if IGNITE_QUIET set to false.
> This makes it's inconvenient to see whether there an issue happened during 
> the streaming or not.
> Suggested improvements:
> - print out errors that happened during the streaming on the streaming side;
> - Future that is returned from {{addData}} methods is not called in case of 
> error. This must be fixed. So that the user is able to write a custom logic 
> around this feature and process errors somehow.



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

[jira] [Resolved] (IGNITE-3425) Missed options in SQL editor.

[Dmitriyff (JIRA)]

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

Dmitriyff resolved IGNITE-3425.
---
Resolution: Fixed
  Assignee: Andrey Novikov  (was: Dmitriyff)

Added fix to support brace autocomplete
Please check it

> Missed options in SQL editor.
> -
>
> Key: IGNITE-3425
> URL: https://issues.apache.org/jira/browse/IGNITE-3425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Andrey Novikov
> Fix For: 1.7
>
>
> On opening of SQL notebook in log showed messages for every paragraph:
> common.0bf89e8….js:12 misspelled option "enableSnippets"
> common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
> common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"
> Also does not work code completion.



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

[jira] [Assigned] (IGNITE-3425) Missed options in SQL editor.

[Dmitriyff (JIRA)]

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

Dmitriyff reassigned IGNITE-3425:
-

Assignee: Dmitriyff

> Missed options in SQL editor.
> -
>
> Key: IGNITE-3425
> URL: https://issues.apache.org/jira/browse/IGNITE-3425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Dmitriyff
> Fix For: 1.7
>
>
> On opening of SQL notebook in log showed messages for every paragraph:
> common.0bf89e8….js:12 misspelled option "enableSnippets"
> common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
> common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"
> Also does not work code completion.



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

[jira] [Created] (IGNITE-3451) Web console: Invalid results of SQL query in area chart

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3451:
-

 Summary: Web console: Invalid results of SQL query in area chart
 Key: IGNITE-3451
 URL: https://issues.apache.org/jira/browse/IGNITE-3451
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.7
Reporter: Vasiliy Sisko


1) Run in demo mode and open SQL page.
2) Execute query:
{code}
SELECT p.name, count(*) AS cnt, 4 as num
FROM "ParkingCache".Parking p
INNER JOIN "CarCache".Car c
  ON (p.id) = (c.parkingId)
GROUP BY P.NAME
{code}
3) Switch results presentation to area charts and configure "Name" or "Row 
index" as X axis and "Num" and "Cnt" as Y axis.
- Initially chart show valid data, but on move cursor chart is rebuilt with 
random data



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

[jira] [Closed] (IGNITE-3445) Web console: Invalid message on save of profile.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko closed IGNITE-3445.
-
Assignee: (was: Vasiliy Sisko)

> Web console: Invalid message on save of profile.
> 
>
> Key: IGNITE-3445
> URL: https://issues.apache.org/jira/browse/IGNITE-3445
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
> Fix For: 1.7
>
>
> Change profile email to other registered and try to save.
> Invalid message is shown: *Failed to save profile: [object Object]*



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

[jira] [Commented] (IGNITE-3445) Web console: Invalid message on save of profile.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-3445:
---

Tested. Showed valid message.

> Web console: Invalid message on save of profile.
> 
>
> Key: IGNITE-3445
> URL: https://issues.apache.org/jira/browse/IGNITE-3445
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> Change profile email to other registered and try to save.
> Invalid message is shown: *Failed to save profile: [object Object]*



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

[jira] [Commented] (IGNITE-3413) Node is not started if continuous query remote filter class is not found

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-3413:
-

Valentin, it's in the branch ignite-3413.
Semen, thanks. OK, I will look into it. At first I fixed it in the same way 
that factory deserialization exceptions are handled.


> Node is not started if continuous query remote filter class is not found
> 
>
> Key: IGNITE-3413
> URL: https://issues.apache.org/jira/browse/IGNITE-3413
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Alexander Paschenko
> Fix For: 1.7
>
> Attachments: ContQueryTest.java
>
>
> Test attached.
> The scenario is the following:
> * First node starts with the special attribute and creates a cache with the 
> node filter that allows to deploy it only on nodes with this attribute.
> * Continuous query with a remote filter is executed.
> * Second node without the attribute is started. It doesn't have the remote 
> filter class, the factory throws an exception and the node doesn't start at 
> all, regardless of the fact that it doesn't even has the cache.



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

[jira] [Resolved] (IGNITE-3445) Web console: Invalid message on save of profile.

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-3445.

Resolution: Fixed
  Assignee: Vasiliy Sisko

Fixed message. Vasiliy, please review.

> Web console: Invalid message on save of profile.
> 
>
> Key: IGNITE-3445
> URL: https://issues.apache.org/jira/browse/IGNITE-3445
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> Change profile email to other registered and try to save.
> Invalid message is shown: *Failed to save profile: [object Object]*



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

[jira] [Closed] (IGNITE-3431) Error message have wrong position when message is longer than 1 row.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-3431.
--
Assignee: (was: Pavel Konstantinov)

Tested too.

> Error message have wrong position when message is longer than 1 row.
> 
>
> Key: IGNITE-3431
> URL: https://issues.apache.org/jira/browse/IGNITE-3431
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
> Fix For: 1.7
>
> Attachments: Wrong message position.png
>
>




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

[jira] [Commented] (IGNITE-3413) Node is not started if continuous query remote filter class is not found

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3413:
--

Alexander, I looked at your changes. Ignore exception on filter creation is 
wrong. Instead we should fix continous query registration logic and do not try 
to register query if cache does not exist on node.

> Node is not started if continuous query remote filter class is not found
> 
>
> Key: IGNITE-3413
> URL: https://issues.apache.org/jira/browse/IGNITE-3413
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Alexander Paschenko
> Fix For: 1.7
>
> Attachments: ContQueryTest.java
>
>
> Test attached.
> The scenario is the following:
> * First node starts with the special attribute and creates a cache with the 
> node filter that allows to deploy it only on nodes with this attribute.
> * Continuous query with a remote filter is executed.
> * Second node without the attribute is started. It doesn't have the remote 
> filter class, the factory throws an exception and the node doesn't start at 
> all, regardless of the fact that it doesn't even has the cache.



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

[jira] [Commented] (IGNITE-3055) IgniteDataStreamer can't be timed out

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3055:
-

Vlad, please take a look at my review notes in the pull-request in addition 
consider the following:

1) Total timeout must be applied in this part of {{doFlush}} method as well

{code}
 for (int i = 0; i < activeFuts0.size(); i++) {
 IgniteInternalFuture f = activeFuts0.get(i);
 
 if (f == null)
 doneCnt++;
 else if (f.isDone()) {
 f.get();
 
 doneCnt++;
 
 activeFuts0.set(i, null);
 }
 else
 break;
 }
{code}

2) In {{closeEx}} method you must use {{busyLock.tryBlock(timeout)}} instead of 
 {{busyLock.block();}}.

3) Test cases:
- check that timeout happens on {{addData}} methods;
- check that timeout happens on {{flush}} and {{close}} methods.

To emulate the timeout you can provide your own implementation of 
{{StreamReceiver}} setting it with {{IgniteDataStreamer.receiver}} method. 
Inside of receiver's implementation you can perform timeout emulation.


> IgniteDataStreamer can't be timed out
> -
>
> Key: IGNITE-3055
> URL: https://issues.apache.org/jira/browse/IGNITE-3055
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Critical
>  Labels: community, customer, important
> Fix For: 1.7
>
>
> In current implementation there is no way to timeout the data streamer. 
> Specifically, {{addData()}} can hang on the parallel operations semaphore and 
> {{close()}} can infinitely wait on one of the futures to complete.
> We should introduce the configurable timeout and fail any data streamer 
> operation if it's exceeded.



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

[jira] [Updated] (IGNITE-3425) Missed options in SQL editor.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-3425:
--
Description: 
On opening of SQL notebook in log showed messages for every paragraph:

common.0bf89e8….js:12 misspelled option "enableSnippets"
common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"

Also does not work code completion.

  was:
On opening of SQL notebook in log showed messages for every paragraph:

common.0bf89e8….js:12 misspelled option "enableSnippets"
common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"


> Missed options in SQL editor.
> -
>
> Key: IGNITE-3425
> URL: https://issues.apache.org/jira/browse/IGNITE-3425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
> Fix For: 1.7
>
>
> On opening of SQL notebook in log showed messages for every paragraph:
> common.0bf89e8….js:12 misspelled option "enableSnippets"
> common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
> common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"
> Also does not work code completion.



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