[jira] [Commented] (IGNITE-5781) Visor throws ClassCastException if cache store implementation is other than CacheJdbcPojoStore

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5781:


Github user Desperus closed the pull request at:

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


> Visor throws ClassCastException if cache store implementation is other than 
> CacheJdbcPojoStore
> --
>
> Key: IGNITE-5781
> URL: https://issues.apache.org/jira/browse/IGNITE-5781
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Aleksandr Meterko
> Fix For: 2.2
>
>
> Issue is reported on user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Visor-and-Cassandra-Cache-Store-td15076.html
> There is an obvious bug in the code. {{VisorCacheJdbcType#list}} method 
> checks the type of store factory like this:
> {code}
> if (factory != null || factory instanceof CacheJdbcPojoStoreFactory) {
> CacheJdbcPojoStoreFactory jdbcFactory = (CacheJdbcPojoStoreFactory) 
> factory;
> {code}
> It should be {{&&}} instead of {{||}}, because otherwise condition will be 
> {{true}} for any factory that is not {{null}}. Even better if {{factory != 
> null}} is removed completely as {{instanceof}} returns {{false}} for {{null}} 
> values anyway.
> However, it's not clear to me why this scenario is reproduced only in certain 
> conditions (see mailing list thread for details). It's possible that there is 
> another hidden bug, this needs to be investigated.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5346) Document SQL Changes: CREATE/DROP, global schema, persistence

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5346:
-

[~dmagda]
this is done via {{Ignite.addCacheConfiguration}} that deals with cache 
templates.

> Document SQL Changes: CREATE/DROP, global schema, persistence 
> --
>
> Key: IGNITE-5346
> URL: https://issues.apache.org/jira/browse/IGNITE-5346
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> We need to document the new features to be added to DDL in 2.1:
> * CREATE and DROP table.
> * Global default schema. 
> * Configuration persistence during restarts.
> In addition, the limitations have to be listed as well:
> * no way to set a schema.
> * ALTER TABLE is to be supported.
> * something?
> Summary of all the changes are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Summary-of-SQL-changes-in-2-1-td18278.html
> Here is a page copy for 2.1:
> https://apacheignite.readme.io/v2.1/docs/distributed-ddl
> Plus, since the schema becomes global it makes sense to revisit all the 
> examples we have where a cache name is used as schema (JOINS). Apply the 
> changes on 2.1 page if needed:
> https://apacheignite.readme.io/v2.1/docs/sql-queries



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5796) Improve cache memory metrics

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-5796:
---

 Summary: Improve cache memory metrics
 Key: IGNITE-5796
 URL: https://issues.apache.org/jira/browse/IGNITE-5796
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Valentin Kulichenko
 Fix For: 2.2


It seems that presently all metrics we have for page memory are about number of 
entries and number of pages.

It would be useful to have metrics showing how much memory in bytes is 
allocated:
* Per memory policy.
* Per cache.
* Separately for data, for indexes and probably other structures that consume 
memory.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5467) Exception in communication SPI can stall the cluster

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-5467.
---

> Exception in communication SPI can stall the cluster
> 
>
> Key: IGNITE-5467
> URL: https://issues.apache.org/jira/browse/IGNITE-5467
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
> Fix For: 2.2
>
> Attachments: MessageSendExceptionTest.java
>
>
> Test attached.
> If there is an exception in {{CommunicationSpi#sendMessage}} while sending 
> response for a cache operation, it can stall whole cluster forever (operation 
> doesn't complete, new nodes can't join, etc.).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5790) Xml config can not be used in jdbs and user code simultaneously

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-5790:
--
Fix Version/s: (was: 2.1)
   2.2

> Xml config can not be used in jdbs and user code simultaneously
> ---
>
> Key: IGNITE-5790
> URL: https://issues.apache.org/jira/browse/IGNITE-5790
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.2
>
>
> when user uses the same xml config for jdbc driver and for his own ignite 
> instance there can be :
> java.sql.SQLException: Failed to start Ignite node.
> Caused by: class org.apache.ignite.IgniteCheckedException: Ignite instance 
> with this name has already been started: CustomeIgniteName
> because JDBC creates separate ignite instance, while user already has one 
> with the same name.
> Of course that can be easily workarounded, user can support two configs or 
> create jdbc connect first and then use Ignition.getOrStart().
> However it's inconvenient for user and should be treated as usability issue.
> I see 2 solutions:
> 1) jdbc driver should use Ignition.getOrStart()
> 2) jdbc driver should connection string as ignite name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-1897) Add failover to write-behind cache store

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-1897:

Issue Type: New Feature  (was: Improvement)

> Add failover to write-behind cache store
> 
>
> Key: IGNITE-1897
> URL: https://issues.apache.org/jira/browse/IGNITE-1897
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>
> Currently there is a possibility of losing database updates if primary node 
> fails. We should maintain updates queue on backup node as well and flush it 
> if needed.
> The implementation should be similar to what is done with continuous queries 
> in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426
> Corresponding user@ thread: 
> http://apache-ignite-users.70518.x6.nabble.com/Write-behind-question-td1936.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5345) Update JDBC driver documentation considering the new implementation

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5345:
-

Please also update the examples under "JDBC" tabs on this page:
https://apacheignite.readme.io/v2.1/docs/distributed-ddl

Presently, the examples use an old version of the driver.

> Update JDBC driver documentation considering the new implementation
> ---
>
> Key: IGNITE-5345
> URL: https://issues.apache.org/jira/browse/IGNITE-5345
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The next version of the JDBC driver is to be released in 2.1. We need to 
> refine the existing documentation explaining:
> * how to connect to the cluster.
> * what's the schema format and options.
> * move the legacy driver versions (like the Ignite client based) to the end 
> of the documentation.
> Here is a documentation page for 2.1:
> https://apacheignite.readme.io/v2.1/docs/jdbc-driver
> [~vozerov], let's discuss how to format the page if needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik edited comment on IGNITE-5123 at 7/20/17 8:09 PM:
-

I am _not_ saying one is better than another (and the example you've provided 
doesn't look that much ticket specific for me, really). I am saying that 
splitting the discussion through the multiple sources makes it harder for 
people to use later.


was (Author: cos):
I am saying one is better than another (and the example you've provided doesn't 
look that much ticket specific for me, really). I am saying that splitting the 
discussion through the multiple sources makes it harder for people to use later.

> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik commented on IGNITE-5123:


I am saying one is better than another (and the example you've provided doesn't 
look that much ticket specific for me, really). I am saying that splitting the 
discussion through the multiple sources makes it harder for people to use later.

> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5123:


[~cos], is my understanding correct that better place to discuss ticket is 
JIRA/PR comments, but not dev list, for example, thread 
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-5123-Review-td19813.html
 ?

> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5786) .NET: Transaction fails with multiple write-through caches

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5786:


The problem seems to be deeper: {{sessionEnd}} must be called once per cache 
store instance. So we need to include store pointer with the {{KEY_SES}} 
probably.

> .NET: Transaction fails with multiple write-through caches
> --
>
> Key: IGNITE-5786
> URL: https://issues.apache.org/jira/browse/IGNITE-5786
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
>  Labels: .NET
> Fix For: 2.2
>
>
> To reproduce: create two caches with {{WriteThrough=true}} and some 
> {{CacheStore}} (implementation can be empty).
> Attempt to update both caches within a transaction:
> {code}
> using (var tx = ignite.GetTransactions().TxStart())
> {
> cache1.Put(1, 1);
> cache2.Put(1, 1);
> tx.Commit();
> }
> {code}
> Exception occurs:
> {code}
> (err) Failed to notify listener: 
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$16@17695df3javax.cache.integration.CacheWriterException:
>  PlatformNativeException [cause=System.InvalidOperationException 
> [idHash=1909546776, hash=1265661973, 
> ClassName=System.InvalidOperationException, Data=null, ExceptionMethod=8
> Get
> Apache.Ignite.Core, Version=2.1.0.19388, Culture=neutral, 
> PublicKeyToken=a487a7ff0b2aaa4a
> Apache.Ignite.Core.Impl.Handle.HandleRegistry
> T Get[T](Int64, Boolean), HelpURL=null, HResult=-2146233079, 
> InnerException=null, Message=Resource handle has been released (is Ignite 
> stopping?)., RemoteStackIndex=0, RemoteStackTraceString=null, 
> Source=Apache.Ignite.Core, StackTraceString=   at 
> Apache.Ignite.Core.Impl.Handle.HandleRegistry.Get[T](Int64 id, Boolean 
> throwOnAbsent) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Handle\HandleRegistry.cs:line
>  262
>at 
> Apache.Ignite.Core.Impl.Cache.Store.CacheStoreInternal`2.Invoke(IBinaryStream 
> stream, Ignite grid) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Store\CacheStoreInternal.cs:line
>  112
>at 
> Apache.Ignite.Core.Impl.Cache.Store.CacheStore.Invoke(PlatformMemoryStream 
> stream, Ignite grid) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Store\CacheStore.cs:line
>  127
>at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreInvoke(Int64 
> memPtr) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
>  366
> {code}
> Explanation:
> * Cache stores share same session within a transaction
> * Session in Java is uses to store .NET session handle, so both stores have 
> the same .NET session (which is good: consistent with Java)
> * Each store calls sessionEnd, so session gets released multiple times - this 
> causes HandleRegistry exception
> Current unit test uses Spring XML with shared 
> {{PlatformDotNetCacheStoreFactory}}, which caches created store instance for 
> some reason, so the bug is hidden, since both caches use the same store 
> instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik commented on IGNITE-5123:


Are we tracking the JIRA in two different places? It might create an 
inconvenience if anyone would ever need to follow through the discussion. It 
makes sense to keep the JIRA discussion on the ticket (or in the PR _if_ such 
PR is named correctly and ASF Infra bot can publish the updates to the JIRA 
automatically).


> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5349) Document C++ Compute Grid

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-5349:
---

Assignee: Prachi Garg  (was: Igor Sapego)

> Document C++ Compute Grid
> -
>
> Key: IGNITE-5349
> URL: https://issues.apache.org/jira/browse/IGNITE-5349
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Prachi Garg
>  Labels: cpp, documentation
> Fix For: 2.1
>
>
> In 2.1 we're introducing compute grid support for C++. It has to be properly 
> documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5349) Document C++ Compute Grid

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5349:
-

Looks good, thanks!

[~pgarg], please review the pages below:
https://apacheignite-cpp.readme.io/v2.1/docs/compute-grid
https://apacheignite-cpp.readme.io/v2.1/docs/fault-tolerance
https://apacheignite-cpp.readme.io/v2.1/docs/load-balancing
https://apacheignite-cpp.readme.io/v2.1/docs/job-scheduling
https://apacheignite-cpp.readme.io/v2.1/docs/distributed-closures

> Document C++ Compute Grid
> -
>
> Key: IGNITE-5349
> URL: https://issues.apache.org/jira/browse/IGNITE-5349
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp, documentation
> Fix For: 2.1
>
>
> In 2.1 we're introducing compute grid support for C++. It has to be properly 
> documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5346) Document SQL Changes: CREATE/DROP, global schema, persistence

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5346:
-

[~al.psc], thanks, I've reviewed and polished the doc. That's the final version 
we have:
* Schema and tables specificities: 
https://apacheignite.readme.io/v2.1/docs/indexes#section-schema-and-tables
* Updated DDL doc with examples for every type of statement: 
https://apacheignite.readme.io/v2.1/docs/distributed-ddl

However, for the TEMPLATE option of the `WITH` clause we're saying the 
following {{Case sensitive name of the cache template registered in Ignite}}. 
But how can I register the template in Ignite? Please explain here.

> Document SQL Changes: CREATE/DROP, global schema, persistence 
> --
>
> Key: IGNITE-5346
> URL: https://issues.apache.org/jira/browse/IGNITE-5346
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> We need to document the new features to be added to DDL in 2.1:
> * CREATE and DROP table.
> * Global default schema. 
> * Configuration persistence during restarts.
> In addition, the limitations have to be listed as well:
> * no way to set a schema.
> * ALTER TABLE is to be supported.
> * something?
> Summary of all the changes are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Summary-of-SQL-changes-in-2-1-td18278.html
> Here is a page copy for 2.1:
> https://apacheignite.readme.io/v2.1/docs/distributed-ddl
> Plus, since the schema becomes global it makes sense to revisit all the 
> examples we have where a cache name is used as schema (JOINS). Apply the 
> changes on 2.1 page if needed:
> https://apacheignite.readme.io/v2.1/docs/sql-queries



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  commented on IGNITE-3950:
---

[~dethmix], 
[^threadDumps.IgniteCacheTestSuite4.txt]
I've attached txt file with 6 thread dumps of all failed by timeout test suites.
I've not found timeouts associated with the IgniteCacheMultiTxLockSelfTest.

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
> Attachments: threadDumps.IgniteCacheTestSuite4.txt
>
>
> Reproduced by 
> IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeysWithClient (hangs with 
> ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  updated IGNITE-3950:
--
Attachment: threadDumps.IgniteCacheTestSuite4.txt

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
> Attachments: threadDumps.IgniteCacheTestSuite4.txt
>
>
> Reproduced by 
> IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeysWithClient (hangs with 
> ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-3950:


[~VitaliyB], Is IgniteCacheMultiTxLockSelfTest hand up occurred in method 
testExplicitLockManyKeysWithClient() ? If yes, it seems this issue is still 
reproducible. 

I've updated issue description, we don't have IgniteCacheMultiLockSelfTest, 
there is only IgniteCacheMultiTxLockSelfTest 

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by 
> IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeysWithClient (hangs with 
> ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-3950:
---
Description: 
Reproduced by IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeysWithClient 
(hangs with ~10% probability).

Exchange worker waits for lock to be released:
{noformat}
Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
Lock 
[object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011, 
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
at 
o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}
while thread that holds lock cannot finish cache operation:
{noformat}
"Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
  java.lang.Thread.State: WAITING
  at sun.misc.Unsafe.park(Unsafe.java:-1)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
  at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
  at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
  at 
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
  at 
org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
{noformat}


  was:
Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
(hangs with ~10% probability).

Exchange worker waits for lock to be released:
{noformat}
Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
Lock 
[object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011, 
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
at 

[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-5795:

Description: 
When cache configured with QueryEntity and used key type with 
@AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
This happens because QueryEntity processing precedes key type registering in 
binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField 
called and unable to resolve type, so null returned and null putted in 
affKeyFields.

On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will 
return null from affKeyFields, but should be affinity key field.

Test that reproduces problem in [PR 
2330|https://github.com/apache/ignite/pull/2330]

To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
will force registering key.

  was:
When cache configured with QueryEntity and used key type with 
@AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
This happens because QueryEntity processing precedes key type registering in 
binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField 
called and unable to resolve type, so null returned and null putted in 
affKeyFields.

On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will 
return null from affKeyFields, but should be affinity key field.

Test that reproduces problem in [PR 
2330|https://github.com/apache/ignite/pull/2330]


> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
> Fix For: 2.2
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-5795:

Description: 
When cache configured with QueryEntity and used key type with 
@AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
This happens because QueryEntity processing precedes key type registering in 
binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField 
called and unable to resolve type, so null returned and null putted in 
affKeyFields.

On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will 
return null from affKeyFields, but should be affinity key field.

Test that reproduces problem in [PR 
2330|https://github.com/apache/ignite/pull/2330]

  was:
When cache configured with QueryEntity and used key type with 
@AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
This happens because QueryEntity processing precedes key type registering in 
binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField 
called and unable to resolve type, so null returned and null putted in 
affKeyFields.

On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will 
return null from affKeyFields, but should be affinity key field.


> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
> Fix For: 2.2
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-2190 at 7/20/17 3:56 PM:
--

TC without timeouted suits.
All fails doesn't belong to the current fix

http://ci.ignite.apache.org/viewModification.html?modId=252010=false=1=vcsModificationBuilds


was (Author: nizhikov):
TC without timeouted suitd.
All fails doesn't belong to the current fix

http://ci.ignite.apache.org/viewModification.html?modId=252010=false=1=vcsModificationBuilds

> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4, 2.0
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.2
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: 

[jira] [Commented] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5795:


GitHub user dkarachentsev opened a pull request:

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

IGNITE-5795 IgniteIGNITE-5795  @AffinityKeyMapped ignored if 
QueryEntity used



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5795

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

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

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

This closes #2330


commit e867266b4cc2f177f39852665ff6c66ef8f59ffe
Author: dkarachentsev 
Date:   2017-07-20T15:54:42Z

IGNITE-5795 Test reproducer.




> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
> Fix For: 2.2
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-5795:
---

 Summary: @AffinityKeyMapped ignored if QueryEntity used
 Key: IGNITE-5795
 URL: https://issues.apache.org/jira/browse/IGNITE-5795
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Dmitry Karachentsev
 Fix For: 2.2


When cache configured with QueryEntity and used key type with 
@AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
This happens because QueryEntity processing precedes key type registering in 
binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField 
called and unable to resolve type, so null returned and null putted in 
affKeyFields.

On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will 
return null from affKeyFields, but should be affinity key field.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5712) Context switching for optimistic transactions

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-5712:
-
Description: Implement context switching between threads for optimistic 
transactions  (was: Implement context switching between threads for optimistic 
transactions
Near , local transaction GridNearTxLocal must be considered only in 
suspend\remove. )

> Context switching for optimistic transactions
> -
>
> Key: IGNITE-5712
> URL: https://issues.apache.org/jira/browse/IGNITE-5712
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Nikolay Izhikov
>
> Implement context switching between threads for optimistic transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5741) Replace HeapByteBuffer to DirectByteBuffer in WAL RecordsIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5741:


GitHub user ilantukh opened a pull request:

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

IGNITE-5741



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5741

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

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

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

This closes #2329


commit 70d0f9918c708cb117e69163cc7b7c119c9a693c
Author: Dmitriy Shabalin 
Date:   2017-07-20T08:08:20Z

IGNITE-4728 Web Console: Saved last succeeded state and redirect to it on 
reload.

commit 02a1bdca57ce6af7fe7636b0a9f99048c89b88b6
Author: Andrey Novikov 
Date:   2017-07-20T08:47:49Z

IGNITE-5788 Web Console: Fixed dependencies for maven project with c3p0.

commit 9479a6ec42fb861a16cc1d46d7b650df3a1bd572
Author: Ilya Lantukh 
Date:   2017-07-20T15:41:52Z

ignite-5741 : Replaced HeapByteBuffer with DirectByteBuffer in WAL reader.




> Replace HeapByteBuffer to DirectByteBuffer in WAL RecordsIterator
> -
>
> Key: IGNITE-5741
> URL: https://issues.apache.org/jira/browse/IGNITE-5741
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.2
>
>
> In current implementation we can get OOM during iterate on wal records, 
> because some wal record may be very large (more that 64Mb). We read using  
> HeapByteBuffer, FileChannel reserve buffer same size as our HeapByteBuffer, 
> but by default FileChannel can not allocate buffer more that 64Mb. (maxMemory 
> = VM.maxDirectMemory()) 
> java-7-oracle
> {code}
> [16:07:54]W:   [org.apache.ignite:ignite-core] [2017-07-12 
> 13:07:54,809][ERROR][exchange-worker-#55966%node0-primary%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=3, 
> minorTopVer=1], nodeId=105056d5, evt=DISCOVERY_CUSTOM_EVT]
> [16:07:54]W:   [org.apache.ignite:ignite-core] 
> java.lang.OutOfMemoryError: Direct buffer memory
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.Bits.reserveMemory(Bits.java:658)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.IOUtil.read(IOUtil.java:195)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.read(RandomAccessFileIO.java:62)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:116)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.ensure(FileInput.java:303)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.readByte(FileInput.java:376)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.readUnsignedByte(FileInput.java:385)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:697)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:673)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> 

[jira] [Updated] (IGNITE-5712) Context switching for optimistic transactions

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-5712:
-
Description: 
Implement context switching between threads for optimistic transactions
Near , local transaction GridNearTxLocal must be considered only in 
suspend\remove. 

  was:
Implement context switching between threads for optimistic transactions
Near , local transaction GridNearTxLocal must be considered only in 
suspend\remove. 

http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2257%2Fhead


> Context switching for optimistic transactions
> -
>
> Key: IGNITE-5712
> URL: https://issues.apache.org/jira/browse/IGNITE-5712
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Nikolay Izhikov
>
> Implement context switching between threads for optimistic transactions
> Near , local transaction GridNearTxLocal must be considered only in 
> suspend\remove. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5750) Format of uptime for metrics

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik commented on IGNITE-5750:


[~ein], do you think it is ready for commit? Please let me know if I can help!

> Format of uptime for metrics
> 
>
> Key: IGNITE-5750
> URL: https://issues.apache.org/jira/browse/IGNITE-5750
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Yevgeniy Ignatyev
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.1
>
>
> Metrics for local node shows uptime formatted as 00:00:00:000
> But the last colon should be changed to the dot.
> Right format is 00:00:00.000



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5123:


[~eignatiev], let me check the results for you. I'll respond to dev list

> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5712) Context switching for optimistic transactions

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-5712:
-
Description: 
Implement context switching between threads for optimistic transactions
Near , local transaction GridNearTxLocal must be considered only in 
suspend\remove. 

http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2257%2Fhead

  was:
Implement context switching between threads for optimistic transactions

http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2257%2Fhead


> Context switching for optimistic transactions
> -
>
> Key: IGNITE-5712
> URL: https://issues.apache.org/jira/browse/IGNITE-5712
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Nikolay Izhikov
>
> Implement context switching between threads for optimistic transactions
> Near , local transaction GridNearTxLocal must be considered only in 
> suspend\remove. 
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2257%2Fhead



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5794) BinaryMetadata is lost if all server nodes have been restarted

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh updated IGNITE-5794:
-
Description: 
Steps to reproduce are described here: 
http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Messages-after-client-reconnect-td15127.html#none

This problem occurs because client has metadata in it's local metadata cache 
and decides that server node should have it too. But server lost it after 
restart.

Possible fixes:
- Make client nodes re-send all contents of local metadata cache after 
reconnect.
- If node doesn't have metadata to process incoming message, it should request 
it from sender node.

  was:
Steps to reproduce are described here: 
http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Messages-after-client-reconnect-tt15127.html

This problem occurs because client has metadata in it's local metadata cache 
and decides that server node should have it too. But server lost it after 
restart.

Possible fixes:
- Make client nodes re-send all contents of local metadata cache after 
reconnect.
- If node doesn't have metadata to process incoming message, it should request 
it from sender node.


> BinaryMetadata is lost if all server nodes have been restarted
> --
>
> Key: IGNITE-5794
> URL: https://issues.apache.org/jira/browse/IGNITE-5794
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>
> Steps to reproduce are described here: 
> http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Messages-after-client-reconnect-td15127.html#none
> This problem occurs because client has metadata in it's local metadata cache 
> and decides that server node should have it too. But server lost it after 
> restart.
> Possible fixes:
> - Make client nodes re-send all contents of local metadata cache after 
> reconnect.
> - If node doesn't have metadata to process incoming message, it should 
> request it from sender node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5794) BinaryMetadata is lost if all server nodes have been restarted

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-5794:


 Summary: BinaryMetadata is lost if all server nodes have been 
restarted
 Key: IGNITE-5794
 URL: https://issues.apache.org/jira/browse/IGNITE-5794
 Project: Ignite
  Issue Type: Bug
  Components: binary, general
Affects Versions: 2.1
Reporter: Ilya Lantukh


Steps to reproduce are described here: 
http://apache-ignite-users.70518.x6.nabble.com/Problem-with-Messages-after-client-reconnect-tt15127.html

This problem occurs because client has metadata in it's local metadata cache 
and decides that server node should have it too. But server lost it after 
restart.

Possible fixes:
- Make client nodes re-send all contents of local metadata cache after 
reconnect.
- If node doesn't have metadata to process incoming message, it should request 
it from sender node.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5791) Block matrix Introduction

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-5791:


Pull request: https://github.com/apache/ignite/pull/2326

Reviewed by [~oignatenko]

> Block matrix Introduction
> -
>
> Key: IGNITE-5791
> URL: https://issues.apache.org/jira/browse/IGNITE-5791
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
> Fix For: 2.2
>
>
> Introduction of sparce distributed block matrix with more efficient 
> multiplication rather than row/col distributed matrix. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Attachment: ttl_hang.patch

> Cache with constant time TTL for entries and enabled persistence hangs for a 
> long time when TTL expirations start
> -
>
> Key: IGNITE-5793
> URL: https://issues.apache.org/jira/browse/IGNITE-5793
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
> Fix For: 2.2
>
> Attachments: ttl_hang.patch
>
>
> Right after expiration time, all threads from sys-stripe pool are busy with 
> removing expired entries, example stacktrace:
> {noformat}
> Thread 
> [name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
> id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
> at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
> at 
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
> at 
> o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
> at 
> o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
> at 
> o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
> at 
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
> at 
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
> at 
> o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
> at 
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
> at 
> o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
> at 
> o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
> at 
> o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
> at 
> o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at 
> o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at 
> o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at 
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
> at 
> o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
> at 
> o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
> at 
> o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at 
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at 
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Patch with reproducer test and expire metrics attached. Put/Get/Expire 
> metrics when expirations start looks like that:
> {noformat}
> [17:21:26,908][INFO 
> ][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
>  Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
> startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
> forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
> pages=259801, reason='timeout']
> @@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
> MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
> allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
> pagesFillFactor=0.0, 

[jira] [Comment Edited] (IGNITE-5750) Format of uptime for metrics

[Yevgeniy Ignatyev (JIRA)]

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

Yevgeniy Ignatyev edited comment on IGNITE-5750 at 7/20/17 2:34 PM:


Yes, I manually checked that uptime format has been changed while Ignite prints 
it to console, I personally do not know or see by searching through Ignite 
codebase what logic or tests can be broken by that change. Could you provide 
some guidance? May be running, e.g. "Run All" configuration on Ignite CI will 
be enough?


was (Author: eignatiev):
Yes, I manually checked that uptime format has been changed, I personally do 
not know or see by searching through Ignite codebase what logic or tests can be 
broken by that change. Could you provide some guidance? May be running, e.g. 
"Run All" configuration on Ignite CI will be enough?

> Format of uptime for metrics
> 
>
> Key: IGNITE-5750
> URL: https://issues.apache.org/jira/browse/IGNITE-5750
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Yevgeniy Ignatyev
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.1
>
>
> Metrics for local node shows uptime formatted as 00:00:00:000
> But the last colon should be changed to the dot.
> Right format is 00:00:00.000



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5750) Format of uptime for metrics

[Yevgeniy Ignatyev (JIRA)]

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

Yevgeniy Ignatyev commented on IGNITE-5750:
---

Yes, I manually checked that uptime format has been changed, I personally do 
not know or see by searching through Ignite codebase what logic or tests can be 
broken by that change. Could you provide some guidance? May be running, e.g. 
"Run All" configuration on Ignite CI will be enough?

> Format of uptime for metrics
> 
>
> Key: IGNITE-5750
> URL: https://issues.apache.org/jira/browse/IGNITE-5750
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Yevgeniy Ignatyev
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.1
>
>
> Metrics for local node shows uptime formatted as 00:00:00:000
> But the last colon should be changed to the dot.
> Right format is 00:00:00.000



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries, example stacktrace:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=45664, pageReplaceRate=0.0, 
physicalMemoryPages=521435}
@@@ putsPerSec=24262  getsPerSec=12399 expiresPerSec=64 
MemoryMetricsSnapshot{name='dfltMemPlc', 

[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()

[Yevgeniy Ignatyev (JIRA)]

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

Yevgeniy Ignatyev commented on IGNITE-5123:
---

Rerun tests in "Run All" Ignite 2.0 group after merge with the latest master - 
http://ci.ignite.apache.org/viewLog.html?buildId=734705=queuedBuildOverviewTab
 - Do you see any issues with them? (Unfortunately I have too little experience 
with Ignite tests to judge.)


> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via 
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference 
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null 
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries, example stacktrace:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operations. The freeze can 
last for several checkpoints. Most likely, system fills cache with new entries 
faster than expiring old. As a result, old entries pile up.
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, 

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries, example stacktrace:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=45664, pageReplaceRate=0.0, 
physicalMemoryPages=521435}
@@@ putsPerSec=24262  getsPerSec=12399 expiresPerSec=64 
MemoryMetricsSnapshot{name='dfltMemPlc', 

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operations. The freeze can 
last for several checkpoints. Most likely, system fills cache with new entries 
faster than expiring old. As a result, old entries pile up.
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operations. The freeze can 
last for several checkpoints. Most likely, system fills cache with new entries 
faster than expiring old. As a result, old entries pile up.
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operations. The freeze can 
last for several checkpoints. Most likely, system fills cache with new entries 
faster than expiring old. As a result, old entries pile up.
Patch with reproducer test and expire metrics attached. Put/Get/Expire metrics 
when expirations start looks like that:
{noformat}
[17:21:26,908][INFO 
][db-checkpoint-thread-#62%database.TtlHangReproducerTest1%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=9e564ba2-8c41-4cf9-bfa8-75e3d50c00dc, 
startPtr=FileWALPointer [idx=64, fileOffset=45383475, len=4459, 
forceFlush=true], checkpointLockWait=0ms, checkpointLockHoldTime=16ms, 
pages=259801, reason='timeout']
@@@ putsPerSec=5459  getsPerSec=3063 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=16846, pageReplaceRate=0.0, 
physicalMemoryPages=515034}
@@@ putsPerSec=15575  getsPerSec=5075 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 
pagesFillFactor=0.0, dirtyPages=37868, pageReplaceRate=0.0, 
physicalMemoryPages=519291}
@@@ putsPerSec=19560  getsPerSec=9210 expiresPerSec=0 
MemoryMetricsSnapshot{name='dfltMemPlc', totalAllocatedPages=0, 
allocationRate=0.0, evictionRate=0.0, largeEntriesPagesPercentage=0.0, 

[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

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

Ivan Rakov updated IGNITE-5793:
---
Description: 
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operations. The freeze can 
last for several checkpoints. Most likely, system fills cache with new entries 
faster than expiring old. As a result, old entries pile up.

  was:
Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 

[jira] [Assigned] (IGNITE-5741) Replace HeapByteBuffer to DirectByteBuffer in WAL RecordsIterator

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-5741:


Assignee: Ilya Lantukh

> Replace HeapByteBuffer to DirectByteBuffer in WAL RecordsIterator
> -
>
> Key: IGNITE-5741
> URL: https://issues.apache.org/jira/browse/IGNITE-5741
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.2
>
>
> In current implementation we can get OOM during iterate on wal records, 
> because some wal record may be very large (more that 64Mb). We read using  
> HeapByteBuffer, FileChannel reserve buffer same size as our HeapByteBuffer, 
> but by default FileChannel can not allocate buffer more that 64Mb. (maxMemory 
> = VM.maxDirectMemory()) 
> java-7-oracle
> {code}
> [16:07:54]W:   [org.apache.ignite:ignite-core] [2017-07-12 
> 13:07:54,809][ERROR][exchange-worker-#55966%node0-primary%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=3, 
> minorTopVer=1], nodeId=105056d5, evt=DISCOVERY_CUSTOM_EVT]
> [16:07:54]W:   [org.apache.ignite:ignite-core] 
> java.lang.OutOfMemoryError: Direct buffer memory
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.Bits.reserveMemory(Bits.java:658)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:174)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.IOUtil.read(IOUtil.java:195)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.read(RandomAccessFileIO.java:62)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:116)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.ensure(FileInput.java:303)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.readByte(FileInput.java:376)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileInput$Crc32CheckingFileInput.readUnsignedByte(FileInput.java:385)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:697)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readRecord(RecordV1Serializer.java:673)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.initReadHandle(AbstractWalRecordsIterator.java:243)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.advanceSegment(FileWriteAheadLogManager.java:2452)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:149)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.(FileWriteAheadLogManager.java:2352)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$RecordsIterator.(FileWriteAheadLogManager.java:2290)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.replay(FileWriteAheadLogManager.java:553)
> [16:07:54]W:   [org.apache.ignite:ignite-core]at 
> 

[jira] [Created] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-5793:
--

 Summary: Cache with constant time TTL for entries and enabled 
persistence hangs for a long time when TTL expirations start
 Key: IGNITE-5793
 URL: https://issues.apache.org/jira/browse/IGNITE-5793
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
 Fix For: 2.2


Right after expiration time, all threads from sys-stripe pool are busy with 
removing expired entries:
{noformat}
Thread 
[name="sys-stripe-3-#35%database.IgniteDbSnapshotWithEvictionsSelfTest1%", 
id=60, state=RUNNABLE, blockCnt=0, waitCnt=101794]
at o.a.i.i.binary.BinaryObjectImpl.typeId(BinaryObjectImpl.java:278)
at 
o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.typeId(CacheObjectBinaryProcessorImpl.java:672)
at 
o.a.i.i.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1688)
at 
o.a.i.i.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2177)
at 
o.a.i.i.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1456)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1419)
at 
o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1241)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3221)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3028)
at 
o.a.i.i.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2961)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at 
o.a.i.i.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at o.a.i.i.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1007)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at 
o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:160)
at 
o.a.i.i.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:854)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1073)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
{noformat}
System totally stops responding to user get/put/etc operation. The freeze can 
last for several checkpoints.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5792) IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint is failing on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5792:
---
Labels: test-fail  (was: )

> IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint 
> is failing on TC
> 
>
> Key: IGNITE-5792
> URL: https://issues.apache.org/jira/browse/IGNITE-5792
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: test-fail
>
> Test 
> IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint 
> started failing on TC.
> Failures must be investigated and fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5792) IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint is failing on TC

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-5792:
---

 Summary: 
IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint is 
failing on TC
 Key: IGNITE-5792
 URL: https://issues.apache.org/jira/browse/IGNITE-5792
 Project: Ignite
  Issue Type: Test
  Components: persistence
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov


Test 
IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint 
started failing on TC.
Failures must be investigated and fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5553:
---
Labels: Muted_test test-fail  (was: test-fail)

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
>  Labels: Muted_test, test-fail
> Fix For: 2.2
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4181) The several runs of ServicesExample causes NPE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4181:


GitHub user x-kreator opened a pull request:

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

ignite-4181

IGNITE-4181 challenge

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

$ git pull https://github.com/x-kreator/ignite ignite-4181

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

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

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

This closes #2325


commit 8c3e64db7d1c6b3059680dc7f003e851dc7c8af3
Author: Dmitry Sorokin 
Date:   2017-07-20T10:00:58Z

IGNITE-4181 challenge: GDPEF.onCacheChangeRequest debug timeout.

commit 3e5be50f5f7c43ad06ba6e67e7e6dbec38a11505
Author: Dmitry Sorokin 
Date:   2017-07-20T11:51:56Z

IGNITE-4181 challenge: + simple test




> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Andrey Kuznetsov
>  Labels: newbie
> Fix For: 2.2
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> 

[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  edited comment on IGNITE-3950 at 7/20/17 12:23 PM:
-

[~dpavlov],

offtop to this issue: If there are free agents, TС will launch additional 
builds. Or you can select a certain agent for your build.

These timeouts were caused by one of these tests:
* IgniteCacheMultiTxLockSelfTest
* CacheGetEntryOptimisticSerializableSeltTest
* CacheGetEntryPessimisticSerializableSeltTest

You can convince yourself of this from the thread dumps.

Default branch has the same results:
 
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=buildTypeHistoryList_Ignite20Tests=%3Cdefault%3E


was (Author: vitaliyb):
[~dpavlov],

offtop to this issue: If there are free agents, TС will launch additional 
builds. Or you can select a certain agent for your build.

These timeouts were caused by one of these tests:
* IgniteCacheMultiTxLockSelfTest
* CacheGetEntryOptimisticSerializableSeltTest
* CacheGetEntryPessimisticSerializableSeltTest

You can convince yourself of this from the thread dumps.

Default branch have the same results:
 
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=buildTypeHistoryList_Ignite20Tests=%3Cdefault%3E

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> 

[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  edited comment on IGNITE-3950 at 7/20/17 12:13 PM:
-

[~dpavlov],

offtop to this issue: If there are free agents, TС will launch additional 
builds. Or you can select a certain agent for your build.

These timeouts were caused by one of these tests:
* IgniteCacheMultiTxLockSelfTest
* CacheGetEntryOptimisticSerializableSeltTest
* CacheGetEntryPessimisticSerializableSeltTest

You can convince yourself of this from the thread dumps.

Default branch have the same results:
 
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=buildTypeHistoryList_Ignite20Tests=%3Cdefault%3E


was (Author: vitaliyb):
[~dpavlov],

offtop to this issue: If there are free agents, TС will launch additional 
builds. Or you can select a certain agent for your build.

These timeouts were caused by one of these tests:
* IgniteCacheMultiTxLockSelfTest
* CacheGetEntryOptimisticSerializableSeltTest
* CacheGetEntryPessimisticSerializableSeltTest

You can convince yourself of this from the thread dumps.

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> 

[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  commented on IGNITE-3950:
---

[~dpavlov],

offtop to this issue: If there are free agents, TС will launch additional 
builds. Or you can select a certain agent for your build.

These timeouts were caused by one of these tests:
* IgniteCacheMultiTxLockSelfTest
* CacheGetEntryOptimisticSerializableSeltTest
* CacheGetEntryPessimisticSerializableSeltTest

You can convince yourself of this from the thread dumps.

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4381) Need ensure that internal threads do not execute blocking operations

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov reassigned IGNITE-4381:
-

Assignee: (was: Konstantin Dudkov)

> Need ensure that internal threads do not execute blocking operations
> 
>
> Key: IGNITE-4381
> URL: https://issues.apache.org/jira/browse/IGNITE-4381
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Semen Boikov
> Fix For: 2.2
>
>
> If internal threads execute blocking operation this can cause starvation and 
> hangs (example of issue https://issues.apache.org/jira/browse/IGNITE-4371).
> Ideally we need a way to 'automatically' find all such places in code, 
> straightforward idea is add assert in GridFutureAdapter.get - assert should 
> fail if it is called by system thread and future is not finished. At least 
> one issue here is that currently system threads can be blocked on operation 
> on utility/marshaller cache, so assert should also take it into account.
> Another idea is execute tests with number of threads in all pools = 1, this 
> also should reveal issues with blocking calls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4672) Optimization: for SQL indexes implement comparison using offheap pointer

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov reassigned IGNITE-4672:
-

Assignee: (was: Konstantin Dudkov)

> Optimization: for SQL indexes implement comparison using offheap pointer
> 
>
> Key: IGNITE-4672
> URL: https://issues.apache.org/jira/browse/IGNITE-4672
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.2
>
>
> Currently for objects comparison in sql indexes we copy full row data on 
> heap, but when index is created on BinaryObject's field and object offheap 
> address is known then it is possible do comparison withput on heap copy and 
> object instantiation. Prototype is implemented in branch 
> ignite-3477-offheap-cmp.
> Note: IGNITE-4629 partially fixes issue with comparison, but it is not 
> possible to use this optimization in all cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4844) Get rid of cache async operations queue

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov reassigned IGNITE-4844:
-

Assignee: (was: Konstantin Dudkov)

> Get rid of cache async operations queue
> ---
>
> Key: IGNITE-4844
> URL: https://issues.apache.org/jira/browse/IGNITE-4844
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
> Fix For: 2.2
>
>
> Now all async cache operations are internally queued and executed 
> sequentially one by one (see for example GridDhtAtomicCache.asyncOp). Need 
> get rid of this queue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5515) GridCacheReplicatedNodeRestartSelfTest hangs

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5515:


There was several timeouts in this suite. Probably related to this tests or 
probably related to IGNITE-5718 fix, needs to be checked
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataGridRestarts_Ignite20Tests=pull%2F2296%2Fhead=buildTypeStatusDiv


> GridCacheReplicatedNodeRestartSelfTest hangs
> 
>
> Key: IGNITE-5515
> URL: https://issues.apache.org/jira/browse/IGNITE-5515
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Pavlov
>  Labels: test-fail
> Fix For: 2.2
>
>
> Sample log: 
> http://ci.ignite.apache.org/viewLog.html?buildId=06=buildResultsDiv=Ignite20Tests_IgniteDataGridRestarts
> Most probably this is the trigger:
> {code}
> [23:26:52]W:   [org.apache.ignite:ignite-core] [2017-06-15 
> 20:26:52,349][ERROR][sys-stripe-22-#191189%replicated.GridCacheReplicatedNodeRestartSelfTest3%][GridNearTxLocal]
>  Commit failed.
> [23:26:52]W:   [org.apache.ignite:ignite-core] class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Commit produced a runtime exception (all transaction entries will be 
> invalidated): 
> GridDhtTxRemote[id=e8aef6dac51--067f-cbd2--0002, 
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=COMMITTING, 
> invalidate=false, rollbackOnly=false, 
> nodeId=64eba958-5741-4cee-ba4b-7ac75d81, duration=0]
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:721)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:790)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1208)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1116)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:95)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:177)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:175)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1032)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:553)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:371)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:301)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:291)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
> [23:26:52]W:   [org.apache.ignite:ignite-core]at 
> 

[jira] [Commented] (IGNITE-5776) Add option to turn on filter reachable addresses in TcpCommunicationSpi

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5776:


Github user asfgit closed the pull request at:

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


> Add option to turn on filter reachable addresses in TcpCommunicationSpi
> ---
>
> Key: IGNITE-5776
> URL: https://issues.apache.org/jira/browse/IGNITE-5776
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
> Fix For: 2.2
>
>
> in the case of  not opened port 7(which is default to check 
> InetAddress.isReachable) each creation of tcpClient will lead to additional 
> delay for 2000ms because of filtering reachable addresses



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5775) Compute runs one job in MetricsUpdateFrequency per thread after all jobs was submitted(as onCollision is not called)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5775:


Github user asfgit closed the pull request at:

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


> Compute runs one job in MetricsUpdateFrequency per thread after all jobs was 
> submitted(as onCollision is not called)
> 
>
> Key: IGNITE-5775
> URL: https://issues.apache.org/jira/browse/IGNITE-5775
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.2
>
> Attachments: Compute.java
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-3950 at 7/20/17 10:14 AM:
--

[~VitaliyB], thank you for this researh!

offtop to this issue: could you please share your experience how to run 
multiple launches? As far as I know, if you run one build configuration few 
times they will be merged and only 1 will be in a queue. Did you use REST API?

About this issue: I see 40 launces and 6 execution timeouts in pull/2322/head. 
This problably related to this issue and probably not. Each of this timeouts 
requires detailed full build log investigation to find out which  was last 
"started test" which testh was hang up. Probability declared in this issue 
(10%) likes similar as current results.


was (Author: dpavlov):
[~VitaliyB], thank you for this researh!

offtop to this issue: could you please share your experience how to you did 
multiple launches? As far as I know, if you run one build configuration few 
times they will be merged and only 1 will be in a queue. Did you use REST API?

About this issue: I see 40 launces and 6 execution timeouts in pull/2322/head. 
This problably related to this issue and probably not. Each of this timeouts 
requires detailed full build log investigation to find out which  was last 
"started test" which testh was hang up. Probability declared in this issue 
(10%) likes similar as current results.

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> 

[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-3950:


[~VitaliyB], thank you for this researh!

offtop to this issue: could you please share your experience how to you did 
multiple launches? As far as I know, if you run one build configuration few 
times they will be merged and only 1 will be in a queue. Did you use REST API?

About this issue: I see 40 launces and 6 execution timeouts in pull/2322/head. 
This problably related to this issue and probably not. Each of this timeouts 
requires detailed full build log investigation to find out which  was last 
"started test" which testh was hang up. Probability declared in this issue 
(10%) likes similar as current results.

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5791) Block matrix Introduction

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5791:
--

 Summary: Block matrix Introduction
 Key: IGNITE-5791
 URL: https://issues.apache.org/jira/browse/IGNITE-5791
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak
 Fix For: 2.2


Introduction of sparce distributed block matrix with more efficient 
multiplication rather than row/col distributed matrix. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-9 at 7/20/17 9:44 AM:


[~yzhdanov] I m going to start posting here a list of new methods for the lock, 
that absent in jdk reentrant read write lock.

getNodeReadHoldCount - Queries the number of reentrant read holds on this lock 
by the current node


was (Author: alexey kuznetsov):
[~yzhdanov] I m going to start posting here a list of new methods for the lock, 
that absent in jdk reentrant read write lock.

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-9) Need to implement IngniteReentrantReadWriteLock

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-9:
---

[~yzhdanov] I m going to start posting here a list of new methods for the lock, 
that absent in jdk reentrant read write lock.

> Need to implement IngniteReentrantReadWriteLock
> ---
>
> Key: IGNITE-9
> URL: https://issues.apache.org/jira/browse/IGNITE-9
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Alexey Kuznetsov
>
> See org.apache.ignite.IgniteLock for reference



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5349) Document C++ Compute Grid

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5349:
-

[~dmagda], done. Please, take a look:
https://apacheignite-cpp.readme.io/v2.1/docs/distributed-closures

> Document C++ Compute Grid
> -
>
> Key: IGNITE-5349
> URL: https://issues.apache.org/jira/browse/IGNITE-5349
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, platforms
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Igor Sapego
>  Labels: cpp, documentation
> Fix For: 2.1
>
>
> In 2.1 we're introducing compute grid support for C++. It has to be properly 
> documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  edited comment on IGNITE-3950 at 7/20/17 9:12 AM:


[~dpavlov],
I've done 40 TC runs for Ignite Cache 4 suite and the issue has not been 
reproduced.
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=2=buildTypeHistoryList_Ignite20Tests=pull%2F2322%2Fhead


was (Author: vitaliyb):
[~dpavlov],
I've done some TC runs for Ignite Cache 4 suite and the issue has not been 
reproduced.
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=2=buildTypeHistoryList_Ignite20Tests=pull%2F2322%2Fhead

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov  commented on IGNITE-3950:
---

[~dpavlov],
I've done some TC runs for Ignite Cache 4 suite and the issue has not been 
reproduced.
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache4=2=buildTypeHistoryList_Ignite20Tests=pull%2F2322%2Fhead

> Deadlock when exchange starts with pending explicit lock
> 
>
> Key: IGNITE-3950
> URL: https://issues.apache.org/jira/browse/IGNITE-3950
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Vitaliy Biryukov 
>  Labels: Muted_test, test-fail
>
> Reproduced by IgniteCacheMultiLockSelfTest#testExplicitLockManyKeysWithClient 
> (hangs with ~10% probability).
> Exchange worker waits for lock to be released:
> {noformat}
> Thread [name="exchange-worker-#155%dht.IgniteCacheMultiTxLockSelfTest3%", 
> id=195, state=TIMED_WAITING, blockCnt=0, waitCnt=44]
> Lock 
> [object=o.a.i.i.processors.cache.GridCacheMvccManager$FinishLockFuture@2638011,
>  ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:187)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:137)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:835)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:763)
> at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:516)
> at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1464)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> while thread that holds lock cannot finish cache operation:
> {noformat}
> "Thread-9@3645" prio=5 tid=0x11a nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$45.inOp(GridCacheAdapter.java:2849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$SyncInOp.op(GridCacheAdapter.java:5303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4351)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2847)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAll(GridCacheProxyImpl.java:838)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(IgniteCacheMultiTxLockSelfTest.java:218)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-1094:
--

[~yzhdanov] There are 5 tests , do you find them sufficient ?
Tests on 2 server nodes:
||Test scenario||Expected result||
|Node 0 initiates cache creation. Both nodes try to create it, but both fail. 
|Exception thrown only on Node 0, cache is reverted.|
|Node 0 initiates cache creation. Both nodes try to create it, but Node 1 
fails. |Exception thrown only on Node 0, cache is reverted.|
|Node 0 initiates corrupted and normal cache. Both nodes try to create them, 
but both fail to create corrupted cache. |Exception thrown only on Node 0, both 
caches are reverted.|
|Node 0 initiates corrupted and normal cache. Both nodes try to create them, 
but Node 1 fail to create corrupted cache. |Exception thrown only on Node 0, 
both caches are reverted.|
|Node 0 initiates 2 corrupted caches. Both nodes try to create them, but Node 1 
fails. |Exception thrown only on Node 0, both caches are reverted.|


> Ignite.createCache(CacheConfiguration) hangs if some exception occurs during 
> cache initialization
> -
>
> Key: IGNITE-1094
> URL: https://issues.apache.org/jira/browse/IGNITE-1094
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Alexey Kuznetsov
>  Labels: Muted_test
> Fix For: 2.2
>
>
> User can pass broken configuration, for example, store factory that throws 
> exception from create() method. I created test to demonstrate the problem. 
> See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' 
> branch 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-5788) Web Console: Missed c3p0 dependencies in generated maven project

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-5788.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: Missed c3p0 dependencies in generated maven project
> 
>
> Key: IGNITE-5788
> URL: https://issues.apache.org/jira/browse/IGNITE-5788
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.2
>
>
> For cluster (JDBC POJO store -> Generic JDBC dialect) dependency: 
> com.mchange.mchange-commons-java:0.2.11 is missed in generated maven project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5788) Web Console: Missed c3p0 dependencies in generated maven project

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-5788:
---

Look good. Tested.

> Web Console: Missed c3p0 dependencies in generated maven project
> 
>
> Key: IGNITE-5788
> URL: https://issues.apache.org/jira/browse/IGNITE-5788
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.2
>
>
> For cluster (JDBC POJO store -> Generic JDBC dialect) dependency: 
> com.mchange.mchange-commons-java:0.2.11 is missed in generated maven project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3474:

Fix Version/s: (was: 2.1)

> Grid hung during load test with warning "Failed to wait for partition map 
> exchange"
> ---
>
> Key: IGNITE-3474
> URL: https://issues.apache.org/jira/browse/IGNITE-3474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Attachments: 132548_id2_172.25.1.33_part.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During load test grid hung:
> {noformat}
> [09:22:17,688][WARN 
> ][exchange-worker-#137%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=97, 
> minorTopVer=0], node=0fe0c0f2-65e1-4ad5-a8c9-92db997fcb7d]. Dumpin
> g pending objects that might be the cause:
> ...
> {noformat}
> See attached file with more info from logs.
> Notes:
> The issue was also reproduced with IGNITE-3239 fixed. So, IGNITE-3239 doesn't 
> seem to be a root cause. 
> Configs:
> 1)
>  - Benchmark name: IgniteCacheRandomOperationBenchmark 
>  - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 4Gb for servers, 1Gb for clients
> - 80 clients, 20 servers, 8 hosts
> - Number of caches: 100
> - Preload amount 250K
> - Key range 500K
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> 2) 
> - Benchmark name: IgniteCacheRandomOperationBenchmark 
> - Operations: scan_query, sql_query, continuous_query
> - Heap: 4Gb for servers, 1Gb for clients
> - 20 clients, 80 servers, 8 hosts
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> Attachments:
> - part of log with the problem (for one of the servers) for config #2
> - xml configs and property file that were used to run yardstick for config #2
> Complete logs can be provided on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova commented on IGNITE-3474:
-

Checked with version 2.1 - not reproduced, close the issue,

> Grid hung during load test with warning "Failed to wait for partition map 
> exchange"
> ---
>
> Key: IGNITE-3474
> URL: https://issues.apache.org/jira/browse/IGNITE-3474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 2.1
>
> Attachments: 132548_id2_172.25.1.33_part.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During load test grid hung:
> {noformat}
> [09:22:17,688][WARN 
> ][exchange-worker-#137%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=97, 
> minorTopVer=0], node=0fe0c0f2-65e1-4ad5-a8c9-92db997fcb7d]. Dumpin
> g pending objects that might be the cause:
> ...
> {noformat}
> See attached file with more info from logs.
> Notes:
> The issue was also reproduced with IGNITE-3239 fixed. So, IGNITE-3239 doesn't 
> seem to be a root cause. 
> Configs:
> 1)
>  - Benchmark name: IgniteCacheRandomOperationBenchmark 
>  - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 4Gb for servers, 1Gb for clients
> - 80 clients, 20 servers, 8 hosts
> - Number of caches: 100
> - Preload amount 250K
> - Key range 500K
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> 2) 
> - Benchmark name: IgniteCacheRandomOperationBenchmark 
> - Operations: scan_query, sql_query, continuous_query
> - Heap: 4Gb for servers, 1Gb for clients
> - 20 clients, 80 servers, 8 hosts
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> Attachments:
> - part of log with the problem (for one of the servers) for config #2
> - xml configs and property file that were used to run yardstick for config #2
> Complete logs can be provided on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3474:

Fix Version/s: 2.1

> Grid hung during load test with warning "Failed to wait for partition map 
> exchange"
> ---
>
> Key: IGNITE-3474
> URL: https://issues.apache.org/jira/browse/IGNITE-3474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 2.1
>
> Attachments: 132548_id2_172.25.1.33_part.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During load test grid hung:
> {noformat}
> [09:22:17,688][WARN 
> ][exchange-worker-#137%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=97, 
> minorTopVer=0], node=0fe0c0f2-65e1-4ad5-a8c9-92db997fcb7d]. Dumpin
> g pending objects that might be the cause:
> ...
> {noformat}
> See attached file with more info from logs.
> Notes:
> The issue was also reproduced with IGNITE-3239 fixed. So, IGNITE-3239 doesn't 
> seem to be a root cause. 
> Configs:
> 1)
>  - Benchmark name: IgniteCacheRandomOperationBenchmark 
>  - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 4Gb for servers, 1Gb for clients
> - 80 clients, 20 servers, 8 hosts
> - Number of caches: 100
> - Preload amount 250K
> - Key range 500K
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> 2) 
> - Benchmark name: IgniteCacheRandomOperationBenchmark 
> - Operations: scan_query, sql_query, continuous_query
> - Heap: 4Gb for servers, 1Gb for clients
> - 20 clients, 80 servers, 8 hosts
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> Attachments:
> - part of log with the problem (for one of the servers) for config #2
> - xml configs and property file that were used to run yardstick for config #2
> Complete logs can be provided on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-3474.
---

> Grid hung during load test with warning "Failed to wait for partition map 
> exchange"
> ---
>
> Key: IGNITE-3474
> URL: https://issues.apache.org/jira/browse/IGNITE-3474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 2.1
>
> Attachments: 132548_id2_172.25.1.33_part.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During load test grid hung:
> {noformat}
> [09:22:17,688][WARN 
> ][exchange-worker-#137%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=97, 
> minorTopVer=0], node=0fe0c0f2-65e1-4ad5-a8c9-92db997fcb7d]. Dumpin
> g pending objects that might be the cause:
> ...
> {noformat}
> See attached file with more info from logs.
> Notes:
> The issue was also reproduced with IGNITE-3239 fixed. So, IGNITE-3239 doesn't 
> seem to be a root cause. 
> Configs:
> 1)
>  - Benchmark name: IgniteCacheRandomOperationBenchmark 
>  - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 4Gb for servers, 1Gb for clients
> - 80 clients, 20 servers, 8 hosts
> - Number of caches: 100
> - Preload amount 250K
> - Key range 500K
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> 2) 
> - Benchmark name: IgniteCacheRandomOperationBenchmark 
> - Operations: scan_query, sql_query, continuous_query
> - Heap: 4Gb for servers, 1Gb for clients
> - 20 clients, 80 servers, 8 hosts
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> Attachments:
> - part of log with the problem (for one of the servers) for config #2
> - xml configs and property file that were used to run yardstick for config #2
> Complete logs can be provided on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova resolved IGNITE-3474.
-
Resolution: Fixed

> Grid hung during load test with warning "Failed to wait for partition map 
> exchange"
> ---
>
> Key: IGNITE-3474
> URL: https://issues.apache.org/jira/browse/IGNITE-3474
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
>Priority: Critical
> Attachments: 132548_id2_172.25.1.33_part.log, 
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During load test grid hung:
> {noformat}
> [09:22:17,688][WARN 
> ][exchange-worker-#137%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=97, 
> minorTopVer=0], node=0fe0c0f2-65e1-4ad5-a8c9-92db997fcb7d]. Dumpin
> g pending objects that might be the cause:
> ...
> {noformat}
> See attached file with more info from logs.
> Notes:
> The issue was also reproduced with IGNITE-3239 fixed. So, IGNITE-3239 doesn't 
> seem to be a root cause. 
> Configs:
> 1)
>  - Benchmark name: IgniteCacheRandomOperationBenchmark 
>  - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 4Gb for servers, 1Gb for clients
> - 80 clients, 20 servers, 8 hosts
> - Number of caches: 100
> - Preload amount 250K
> - Key range 500K
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> 2) 
> - Benchmark name: IgniteCacheRandomOperationBenchmark 
> - Operations: scan_query, sql_query, continuous_query
> - Heap: 4Gb for servers, 1Gb for clients
> - 20 clients, 80 servers, 8 hosts
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 1
> - Duration: 1h
> Attachments:
> - part of log with the problem (for one of the servers) for config #2
> - xml configs and property file that were used to run yardstick for config #2
> Complete logs can be provided on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-5767:


[~vsisko], please add test for mapping {{BINARY}} type.

> Web console: use byte array type instead of java.lang.Object for binary JDBC 
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> Schema importer should use {{[B}} query entity field type instead of 
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}} 
> and {{LONGVARBINARY}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5767:
--

Assignee: Vasiliy Sisko  (was: Andrey Novikov)

> Web console: use byte array type instead of java.lang.Object for binary JDBC 
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Vasiliy Sisko
> Fix For: 2.2
>
>
> Schema importer should use {{[B}} query entity field type instead of 
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}} 
> and {{LONGVARBINARY}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-4728) Web Console: Remember the screen from which user has left the previous session.

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-4728.
--

> Web Console: Remember the screen from which user has left the previous 
> session.
> ---
>
> Key: IGNITE-4728
> URL: https://issues.apache.org/jira/browse/IGNITE-4728
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
> Attachments: ignite-4728.png
>
>
> Don't save latest state for demo mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4728) Web Console: Remember the screen from which user has left the previous session.

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-4728:
--

Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: Remember the screen from which user has left the previous 
> session.
> ---
>
> Key: IGNITE-4728
> URL: https://issues.apache.org/jira/browse/IGNITE-4728
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
> Attachments: ignite-4728.png
>
>
> Don't save latest state for demo mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev updated IGNITE-5789:
--
Attachment: ClientReconnectAfterClusterRestartTest.java

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev updated IGNITE-5789:
--
Summary: After client reconnects to server if server was restarted, client 
doesn't create caches defined in client's configuration  (was: After client 
reconnects to server if server was restarted, client doesn't create caches 
defined in config file)

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in config file

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5789:
-

 Summary: After client reconnects to server if server was 
restarted, client doesn't create caches defined in config file
 Key: IGNITE-5789
 URL: https://issues.apache.org/jira/browse/IGNITE-5789
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Evgenii Zhuravlev






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5754) Web Console: Web agent should use POST instead of GET to get topology

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5754:
--

Assignee: Alexey Kuznetsov  (was: Aleksey Chetaev)

> Web Console: Web agent should use POST instead of GET to get topology
> -
>
> Key: IGNITE-5754
> URL: https://issues.apache.org/jira/browse/IGNITE-5754
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.2
>
>
> On large topology Web Agent generate very long GET request and node that 
> handle that request throw error: "URI is too large > 8192"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5754) Web Console: Web agent should use POST instead of GET to get topology

[Andrey Novikov (JIRA)]

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

Andrey Novikov edited comment on IGNITE-5754 at 7/20/17 7:50 AM:
-

Used POST in Web Agent requests instead of GET.

[~kuaw26], please review my changes


was (Author: anovikov):
Used POST in Web Agent requests instead of GET.

> Web Console: Web agent should use POST instead of GET to get topology
> -
>
> Key: IGNITE-5754
> URL: https://issues.apache.org/jira/browse/IGNITE-5754
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> On large topology Web Agent generate very long GET request and node that 
> handle that request throw error: "URI is too large > 8192"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5754) Web Console: Web agent should use POST instead of GET to get topology

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5754:
--

Assignee: Aleksey Chetaev  (was: Andrey Novikov)

> Web Console: Web agent should use POST instead of GET to get topology
> -
>
> Key: IGNITE-5754
> URL: https://issues.apache.org/jira/browse/IGNITE-5754
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Chetaev
> Fix For: 2.2
>
>
> On large topology Web Agent generate very long GET request and node that 
> handle that request throw error: "URI is too large > 8192"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5734) Web Console: update npm dependensies

[Andrey Novikov (JIRA)]

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

Andrey Novikov edited comment on IGNITE-5734 at 7/20/17 7:48 AM:
-

Updated deps Also updated ui-router to laster version [~Klaster_1], Can you 
please have a look?


was (Author: anovikov):
Updated deps

> Web Console: update npm dependensies
> 
>
> Key: IGNITE-5734
> URL: https://issues.apache.org/jira/browse/IGNITE-5734
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> Before major release we can update npm dependencies.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5734) Web Console: update npm dependensies

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5734:
--

Assignee: Ilya Borisov  (was: Andrey Novikov)

> Web Console: update npm dependensies
> 
>
> Key: IGNITE-5734
> URL: https://issues.apache.org/jira/browse/IGNITE-5734
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Ilya Borisov
> Fix For: 2.2
>
>
> Before major release we can update npm dependencies.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5788) Web Console: Missed c3p0 dependencies in generated maven project

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5788:
--

Assignee: Andrey Novikov

> Web Console: Missed c3p0 dependencies in generated maven project
> 
>
> Key: IGNITE-5788
> URL: https://issues.apache.org/jira/browse/IGNITE-5788
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.2
>
>
> For cluster (JDBC POJO store -> Generic JDBC dialect) dependency: 
> com.mchange.mchange-commons-java:0.2.11 is missed in generated maven project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4648) IgniteInternalTx.prepare() does not wait for async operations to complete

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4648:


[~avinogradov], [~yzhdanov], [~ptupitsyn], I added boolean flag to 
{{prepare()}} method. 
[JTA|http://ci.ignite.apache.org/viewLog.html?buildId=733943=Ignite20Tests_IgniteJta=buildResultsDiv]
 and 
[.NET|http://ci.ignite.apache.org/viewLog.html?buildId=733942=buildResultsDiv=Ignite20Tests_RunAllNet]
 tests are successfully completed.

> IgniteInternalTx.prepare() does not wait for async operations to complete
> -
>
> Key: IGNITE-4648
> URL: https://issues.apache.org/jira/browse/IGNITE-4648
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.2
>
>
> {{commit}} and {{rollback}} wait for async operations by calling 
> {{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).
> There is no such thing in {{IgniteInternalTx.prepare()}} implementations.
> Since {{prepare}} is an internal method, this is not an issue mostly, except 
> for two things:
> * JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
> * .NET {{TransactionScope}} API. Same thing as JTA, basically. 
> {{PlatformTransactions}} call {{prepare()}} as well.
> As a result, if user starts an async operation within JTA transaction and 
> then completes the tx, undefined behavior is possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5788) Web Console: Missed c3p0 dependencies in generated maven project

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-5788:
--

 Summary: Web Console: Missed c3p0 dependencies in generated maven 
project
 Key: IGNITE-5788
 URL: https://issues.apache.org/jira/browse/IGNITE-5788
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Andrey Novikov
Priority: Minor
 Fix For: 2.2


For cluster (JDBC POJO store -> Generic JDBC dialect) dependency: 
com.mchange.mchange-commons-java:0.2.11 is missed in generated maven project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-5767:
-

Assignee: Andrey Novikov  (was: Vasiliy Sisko)

Fixed an associated type for BINARY JDBC type to byte[].

> Web console: use byte array type instead of java.lang.Object for binary JDBC 
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Andrey Novikov
> Fix For: 2.2
>
>
> Schema importer should use {{[B}} query entity field type instead of 
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}} 
> and {{LONGVARBINARY}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-5767:
-

Assignee: Vasiliy Sisko  (was: Andrey Novikov)

> Web console: use byte array type instead of java.lang.Object for binary JDBC 
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Vasiliy Sisko
> Fix For: 2.2
>
>
> Schema importer should use {{[B}} query entity field type instead of 
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}} 
> and {{LONGVARBINARY}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)