[jira] [Commented] (IGNITE-13061) Grid could start with one wal segment
[
https://issues.apache.org/jira/browse/IGNITE-13061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114979#comment-17114979
]
Ignite TC Bot commented on IGNITE-13061:
{panel:title=Branch: [pull/7836/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5329818buildTypeId=IgniteTests24Java8_RunAll]
> Grid could start with one wal segment
> -
>
> Key: IGNITE-13061
> URL: https://issues.apache.org/jira/browse/IGNITE-13061
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now it is able to set one wal segment in grid config and grid starts fine.
> It could lead to strange side-effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12929) Incorrect setClientMode calls instead of startClientGrid
[
https://issues.apache.org/jira/browse/IGNITE-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12929:
-
Description:
There were some places left after IGNITE-12493 merge where {{setClientMode}}
instead of {{startClientGrid}}.
Need to be fixed.
Check also references of:
{{org.apache.ignite.util.GridCommandHandlerAbstractTest#CLIENT_NODE_NAME_PREFIX}}.
Examples:
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/database/IgniteDbAbstractTest.java#L168
https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/SqlCacheStartStopTest.java#L81
was:
There were some places left after IGNITE-12493 merge where {{setClientMode}}
instead of {{startClientGrid}}.
Need to be fixed.
Examples:
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/database/IgniteDbAbstractTest.java#L168
https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/SqlCacheStartStopTest.java#L81
> Incorrect setClientMode calls instead of startClientGrid
>
>
> Key: IGNITE-12929
> URL: https://issues.apache.org/jira/browse/IGNITE-12929
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
>
> There were some places left after IGNITE-12493 merge where {{setClientMode}}
> instead of {{startClientGrid}}.
> Need to be fixed.
> Check also references of:
> {{org.apache.ignite.util.GridCommandHandlerAbstractTest#CLIENT_NODE_NAME_PREFIX}}.
> Examples:
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/database/IgniteDbAbstractTest.java#L168
> https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/SqlCacheStartStopTest.java#L81
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13063) Bottom-up index rebuild
[ https://issues.apache.org/jira/browse/IGNITE-13063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13063: - Labels: iep-22 (was: ) > Bottom-up index rebuild > --- > > Key: IGNITE-13063 > URL: https://issues.apache.org/jira/browse/IGNITE-13063 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-22 > > As part of [IEP-22: Direct Data > Load|https://cwiki.apache.org/confluence/display/IGNITE/IEP-22%3A+Direct+Data+Load] > the PoC needs to be implemented for the new algorithm of rebuilding an index. > Compare the approach of the bottom-up index rebuild with the default > implementation (from the root). > See details in the IEP-22. > h4. High-level overview > We will not update PK and secondary indexes during the data load, so it is > necessary to rebuild them in the end. The most efficient way to build indexes > is bottom-up approach, when the lowest level of BTree is built first, and the > root is build last. We will need a buffer where indexed values and respective > links will be sorted in index order. If the buffer is big enough and all the > data fits into it, index will be created in one hop. Otherwise it is > necessary to sort indexed values in several runs using an external sort. It > is necessary to let users configure sort parameters - buffer size (ideally - > in bytes), and the file system path where temp files will be stored. The > latter is critical - typically users would like to keep temp files on a > separate disk, so that WAL and checkpoint operations are not affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13067) AssertionError waiting response from primary for thin client
Maxim Muzafarov created IGNITE-13067:
Summary: AssertionError waiting response from primary for thin
client
Key: IGNITE-13067
URL: https://issues.apache.org/jira/browse/IGNITE-13067
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
The thin client TeamCity suite fails with assertion error. Investigation and
reproducer required.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeStatusDiv_IgniteTests24Java8=%3Cdefault%3E
{code:java}
[00:58:49]W: [org.apache.ignite:ignite-indexing]
java.lang.AssertionError[00:58:49]W: [org.apache.ignite:ignite-indexing]
java.lang.AssertionError[00:58:49]W: [org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:246)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3338)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:141)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:292)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:287)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)[00:58:49]W:
[org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)[00:58:49]W:
[org.apache.ignite:ignite-indexing]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13066:
-
Summary: Test framework must print which tests for quite mode (was: Test
framework must print which tests start regardless logger configured or not)
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13066) Test framework must print which tests start regardless logger configured or not
Maxim Muzafarov created IGNITE-13066:
Summary: Test framework must print which tests start regardless
logger configured or not
Key: IGNITE-13066
URL: https://issues.apache.org/jira/browse/IGNITE-13066
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
For most of the TeamCity test suites logger is turned off for performance
reasons (log size can be more than a thousand MB). In case of exceptions
happened it's hard to identify which of running tests fail.
It is necessary to log which tests are started regardless of the logger
configured or not.
Example:
{code:java}
info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114752#comment-17114752
]
Ivan Daschinskiy commented on IGNITE-10940:
---
Absolutelly agree with [~alex_pl]
First of all in order to build Ignite.C++ one should install libboost-dev,
libssl-dev, g++, build-essentials, optionally unixodbc-dev. And (I hardly
believe that C++ developer doesn't have them installed already) just add to
this list autotools and libtool is not a big problem.
I suppose, that the right direction is migrating to cmake and C++ 11. But this
patch just adds problems, but not solve the root cause -- Ignite C++ should be
modernized.
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build, platforms
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: c++
> Fix For: 2.9
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12078) implement loadCache on CacheJdbcBlobStore
[ https://issues.apache.org/jira/browse/IGNITE-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114705#comment-17114705 ] Manuel commented on IGNITE-12078: - I've check this problem on 2.8.0 version and the problem persist. Any notice for this issue? > implement loadCache on CacheJdbcBlobStore > - > > Key: IGNITE-12078 > URL: https://issues.apache.org/jira/browse/IGNITE-12078 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7.5 >Reporter: Luca >Priority: Major > > When store a cache persistent in a 3rd Party Storage as Blob the > CacheJdbcBlobStoreFactory is used. According to the documentation > ([https://apacheignite.readme.io/v1.9/docs/persistent-store#section-loadcache-] > / [https://apacheignite.readme.io/docs/data-loading#ignitecacheloadcache]) > the method loadCache() should be used to load the data from the persistent > storage back to the cache. > Unfortunately the loadCache() method is only implemented in the > CacheJdbcPojoStore but not in the CacheJdbcBlobStore. > PR: https://github.com/apache/ignite/pull/6783 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114690#comment-17114690
]
Aleksey Plekhanov commented on IGNITE-10940:
[~ilyak], the patch adds external dependencies to some libraries which are not
preinstalled on some systems (at least MacOS and Windows). It makes release
process platform dependent. Before the patch to build Ignite all you needed is
maven, which downloads all other dependencies, but now you need to download and
install libtool, which is not related at all to java development. For a small
part of C++ users we broke the build for another, much larger part of users.
Moreover, there are no notes about it on DEVNOTES. Java contributors will try
to build the project by {{mvn initialize -Prelease}} command and build will
fail. I think such a feature should be at least optional, and perhaps disabled
by default with a description in DEVNOTES about how to enable it.
Another question, why such a change not discussed on dev-list?
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build, platforms
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: c++
> Fix For: 2.9
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
