[jira] [Commented] (IGNITE-5781) Visor throws ClassCastException if cache store implementation is other than CacheJdbcPojoStore
[ https://issues.apache.org/jira/browse/IGNITE-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(
[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&personal=false&init=1&tab=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&personal=false&init=1&tab=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.T
[jira] [Commented] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used
[ https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.initReadHandle(AbstractWalRecordsIterator.java:243) > [16:07:54]W:
[jira] [Updated] (IGNITE-5712) Context switching for optimistic transactions
[ 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&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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&branch_Ignite20Tests=pull%2F2257%2Fhead was: Implement context switching between threads for optimistic transactions http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_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&branch_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
[ 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 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
[ https://issues.apache.org/jira/browse/IGNITE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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, dirtyPages
[jira] [Comment Edited] (IGNITE-5750) Format of uptime for metrics
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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', totalAllocatedPage
[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
[ https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=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
[ 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, largeEntriesPagesPe
[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start
[ 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', totalAllocatedPage
[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start
[ 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, pages
[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start
[ 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, pages
[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start
[ 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, pages
[jira] [Updated] (IGNITE-5793) Cache with constant time TTL for entries and enabled persistence hangs for a long time when TTL expirations start
[ 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 o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCache
[jira] [Assigned] (IGNITE-5741) Replace HeapByteBuffer to DirectByteBuffer in WAL RecordsIterator
[ 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 > org.apache.ignite.internal.processors.
[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 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
[ 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 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
[ 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&testNameId=-7043871603266099589&tab=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
[ https://issues.apache.org/jira/browse/IGNITE-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.internal.processors.cache.CacheAffinityShar
[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildTypeHistoryList&branch_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&tab=buildTypeHistoryList&branch_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 > org.apache.ignite.internal.process
[jira] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildTypeHistoryList&branch_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 > org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheMultiTxLockSelfTest$1.run(Ign
[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&branch_Ignite20Tests=pull%2F2296%2Fhead&tab=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&tab=buildResultsDiv&buildTypeId=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 > org.apach
[jira] [Commented] (IGNITE-5776) Add option to turn on filter reachable addresses in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/IGNITE-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.ignite.internal.pro
[jira] [Commented] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (IGNITE-5790) Xml config can not be used in jdbs and user code simultaneously
Mikhail Cherkasov created IGNITE-5790: - Summary: 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.1 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] [Comment Edited] (IGNITE-3950) Deadlock when exchange starts with pending explicit lock
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&page=2&tab=buildTypeHistoryList&branch_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&page=2&tab=buildTypeHistoryList&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&page=2&tab=buildTypeHistoryList&branch_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
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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"
[ 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"
[ https://issues.apache.org/jira/browse/IGNITE-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"
[ 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] [Updated] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"
[ 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] [Resolved] (IGNITE-3474) Grid hung during load test with warning "Failed to wait for partition map exchange"
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
[ 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.
[ 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
[ 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
[ 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 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&buildTypeId=Ignite20Tests_IgniteJta&tab=buildResultsDiv] and [.NET|http://ci.ignite.apache.org/viewLog.html?buildId=733942&tab=buildResultsDiv&buildTypeId=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 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
[ 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
[ 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)