Re: Change Ignite download.cgi page to satisfy requirements
Maxim, thanks a lot for picking up this task! Glad to see you contributing to the website. - Denis On Tue, Apr 14, 2020 at 3:34 PM Maxim Muzafarov wrote: > Folks, > > > The Apache Ignite download page has been updated. > Thanks, everyone for the help. > > https://ignite.apache.org/download.cgi > > On Wed, 15 Apr 2020 at 00:22, Nikolay Izhikov wrote: > > > > I’ve added this files to the ignite svn. > > > > > 14 апр. 2020 г., в 01:57, Maxim Muzafarov > написал(а): > > > > > > Folks, > > > > > > > > > As another suggestion, we can place such files (pgp, sha512) here > > > https://downloads.apache.org/ignite/gce/ (`gce` directory must be > > > created). I don't have access rights there. > > > > > > All files have been prepared by me. I'm ready to provide them. > > > > > > On Mon, 13 Apr 2020 at 19:49, Denis Magda wrote: > > >> > > >> I'm ok with that approach. Petr, what's your thinking? > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Fri, Apr 10, 2020 at 4:20 PM Maxim Muzafarov > wrote: > > >> > > >>> Denis, Petr > > >>> > > >>> If I'll prepare pgp and sha512 for this Google Compute Image file [1] > > >>> is there any official repository where we can store these files to > use > > >>> them? > > >>> Can we upload them to the storage.googleapis.com/ignite-media site? > > >>> > > >>> [1] > https://storage.googleapis.com/ignite-media/ignite-google-image.tar.gz > > >>> > > >>> On Tue, 7 Apr 2020 at 18:56, Denis Magda wrote: > > > > Maxim, please go ahead and update the page. > > > > - > > Denis > > > > > > On Mon, Apr 6, 2020 at 7:24 PM Maxim Muzafarov > > >>> wrote: > > > > > Denis, > > > > > > Since the Apache Ignite website has been updated and moved to git > can > > > we proceed with changing the `download.cgi` page [2]? > > > > > > > > > [1] https://ignite.apache.org/download.cgi > > > [2] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > > > On Sat, 28 Mar 2020 at 01:55, Denis Magda > wrote: > > >> > > >> Agreed, > > >> > > >> I'll ask INFRA to proceed with the Git migration first days next > > >>> week. > > >> Please wait while the migration ends. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov < > mmu...@apache.org> > > > wrote: > > >> > > >>> Denis, > > >>> > > >>> I think we can move to git first. I'll do the changes discussed > > >>> above > > >>> by the end of the next week. > > >>> > > >>> On Fri, 27 Mar 2020 at 20:55, Denis Magda > > >>> wrote: > > > > Maxim, > > > > The new website is launched [1] and we can proceed with the > > >>> changes > > discussed in this thread. > > > > Will you have time to implement those next week? If it's highly > > > unlikely > > then I would request INFRA to move the website to Git first. > > > > [1] > > > > >>> > > > > > >>> > http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html > > > > - > > Denis > > > > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda > > > wrote: > > > > > Hi Maxim, > > > > > > Here is a ticket [1] where I've collected INFRA recommendations > > > shared > > >>> in > > > an adjacent discussion thread. Please check it, add anything > > >>> new > > > you > > >>> heard > > > from them. > > > > > > Feel free to take over this task, appreciate your help. > > >>> However, > > > please > > > give me a couple of days to finish the merge of the new > > >>> website to > > > the > > > master branch. After that, you can update the downloads page > > >>> and > > > I'll > > > request INFRA to move the website to a Git repository. I'll > > >>> send a > > > note > > > here once the new website is released. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > > > - > > > Denis > > > > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov < > > >>> mmu...@apache.org > > >> > > >>> wrote: > > > > > >> Igniters, > > >> > > >> > > >> I've recently found that some of our releases were missed at > > >>> the > > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. > > >> > > >> I've contacted the Apache announce list moderators and got the > > >> requirements for our download page [6] (see the message > > >>> below). > > > I'm > > >> going to update the download page on the Apache Ignite website > > >> according to received instructions using these pages as an > > > example [1] > >
Re: Change Ignite download.cgi page to satisfy requirements
Folks, The Apache Ignite download page has been updated. Thanks, everyone for the help. https://ignite.apache.org/download.cgi On Wed, 15 Apr 2020 at 00:22, Nikolay Izhikov wrote: > > I’ve added this files to the ignite svn. > > > 14 апр. 2020 г., в 01:57, Maxim Muzafarov написал(а): > > > > Folks, > > > > > > As another suggestion, we can place such files (pgp, sha512) here > > https://downloads.apache.org/ignite/gce/ (`gce` directory must be > > created). I don't have access rights there. > > > > All files have been prepared by me. I'm ready to provide them. > > > > On Mon, 13 Apr 2020 at 19:49, Denis Magda wrote: > >> > >> I'm ok with that approach. Petr, what's your thinking? > >> > >> - > >> Denis > >> > >> > >> On Fri, Apr 10, 2020 at 4:20 PM Maxim Muzafarov wrote: > >> > >>> Denis, Petr > >>> > >>> If I'll prepare pgp and sha512 for this Google Compute Image file [1] > >>> is there any official repository where we can store these files to use > >>> them? > >>> Can we upload them to the storage.googleapis.com/ignite-media site? > >>> > >>> [1] https://storage.googleapis.com/ignite-media/ignite-google-image.tar.gz > >>> > >>> On Tue, 7 Apr 2020 at 18:56, Denis Magda wrote: > > Maxim, please go ahead and update the page. > > - > Denis > > > On Mon, Apr 6, 2020 at 7:24 PM Maxim Muzafarov > >>> wrote: > > > Denis, > > > > Since the Apache Ignite website has been updated and moved to git can > > we proceed with changing the `download.cgi` page [2]? > > > > > > [1] https://ignite.apache.org/download.cgi > > [2] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > On Sat, 28 Mar 2020 at 01:55, Denis Magda wrote: > >> > >> Agreed, > >> > >> I'll ask INFRA to proceed with the Git migration first days next > >>> week. > >> Please wait while the migration ends. > >> > >> - > >> Denis > >> > >> > >> On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov > > wrote: > >> > >>> Denis, > >>> > >>> I think we can move to git first. I'll do the changes discussed > >>> above > >>> by the end of the next week. > >>> > >>> On Fri, 27 Mar 2020 at 20:55, Denis Magda > >>> wrote: > > Maxim, > > The new website is launched [1] and we can proceed with the > >>> changes > discussed in this thread. > > Will you have time to implement those next week? If it's highly > > unlikely > then I would request INFRA to move the website to Git first. > > [1] > > >>> > > > >>> http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html > > - > Denis > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda > > wrote: > > > Hi Maxim, > > > > Here is a ticket [1] where I've collected INFRA recommendations > > shared > >>> in > > an adjacent discussion thread. Please check it, add anything > >>> new > > you > >>> heard > > from them. > > > > Feel free to take over this task, appreciate your help. > >>> However, > > please > > give me a couple of days to finish the merge of the new > >>> website to > > the > > master branch. After that, you can update the downloads page > >>> and > > I'll > > request INFRA to move the website to a Git repository. I'll > >>> send a > > note > > here once the new website is released. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > - > > Denis > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov < > >>> mmu...@apache.org > >> > >>> wrote: > > > >> Igniters, > >> > >> > >> I've recently found that some of our releases were missed at > >>> the > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. > >> > >> I've contacted the Apache announce list moderators and got the > >> requirements for our download page [6] (see the message > >>> below). > > I'm > >> going to update the download page on the Apache Ignite website > >> according to received instructions using these pages as an > > example [1] > >> [2]. > >> > >> WDYT? > >> > >> > >> Denis, > >> > >> Do we have maintainer here or I can proceed with this by > >>> myself? > >> > >> > >>> > > >> > >> Sorry, but the download page does not meet the requirements. > >> > >> 1) There is no link to the KEYS file > >> https://downloads.apache.org/ignite/KEYS > >> This is necessary for validating
Re: Change Ignite download.cgi page to satisfy requirements
I’ve added this files to the ignite svn. > 14 апр. 2020 г., в 01:57, Maxim Muzafarov написал(а): > > Folks, > > > As another suggestion, we can place such files (pgp, sha512) here > https://downloads.apache.org/ignite/gce/ (`gce` directory must be > created). I don't have access rights there. > > All files have been prepared by me. I'm ready to provide them. > > On Mon, 13 Apr 2020 at 19:49, Denis Magda wrote: >> >> I'm ok with that approach. Petr, what's your thinking? >> >> - >> Denis >> >> >> On Fri, Apr 10, 2020 at 4:20 PM Maxim Muzafarov wrote: >> >>> Denis, Petr >>> >>> If I'll prepare pgp and sha512 for this Google Compute Image file [1] >>> is there any official repository where we can store these files to use >>> them? >>> Can we upload them to the storage.googleapis.com/ignite-media site? >>> >>> [1] https://storage.googleapis.com/ignite-media/ignite-google-image.tar.gz >>> >>> On Tue, 7 Apr 2020 at 18:56, Denis Magda wrote: Maxim, please go ahead and update the page. - Denis On Mon, Apr 6, 2020 at 7:24 PM Maxim Muzafarov >>> wrote: > Denis, > > Since the Apache Ignite website has been updated and moved to git can > we proceed with changing the `download.cgi` page [2]? > > > [1] https://ignite.apache.org/download.cgi > [2] https://issues.apache.org/jira/browse/IGNITE-12775 > > On Sat, 28 Mar 2020 at 01:55, Denis Magda wrote: >> >> Agreed, >> >> I'll ask INFRA to proceed with the Git migration first days next >>> week. >> Please wait while the migration ends. >> >> - >> Denis >> >> >> On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov > wrote: >> >>> Denis, >>> >>> I think we can move to git first. I'll do the changes discussed >>> above >>> by the end of the next week. >>> >>> On Fri, 27 Mar 2020 at 20:55, Denis Magda >>> wrote: Maxim, The new website is launched [1] and we can proceed with the >>> changes discussed in this thread. Will you have time to implement those next week? If it's highly > unlikely then I would request INFRA to move the website to Git first. [1] >>> > >>> http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html - Denis On Wed, Mar 25, 2020 at 9:47 AM Denis Magda > wrote: > Hi Maxim, > > Here is a ticket [1] where I've collected INFRA recommendations > shared >>> in > an adjacent discussion thread. Please check it, add anything >>> new > you >>> heard > from them. > > Feel free to take over this task, appreciate your help. >>> However, > please > give me a couple of days to finish the merge of the new >>> website to > the > master branch. After that, you can update the downloads page >>> and > I'll > request INFRA to move the website to a Git repository. I'll >>> send a > note > here once the new website is released. > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > - > Denis > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov < >>> mmu...@apache.org >> >>> wrote: > >> Igniters, >> >> >> I've recently found that some of our releases were missed at >>> the >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. >> >> I've contacted the Apache announce list moderators and got the >> requirements for our download page [6] (see the message >>> below). > I'm >> going to update the download page on the Apache Ignite website >> according to received instructions using these pages as an > example [1] >> [2]. >> >> WDYT? >> >> >> Denis, >> >> Do we have maintainer here or I can proceed with this by >>> myself? >> >> >>> > >> >> Sorry, but the download page does not meet the requirements. >> >> 1) There is no link to the KEYS file >> https://downloads.apache.org/ignite/KEYS >> This is necessary for validating downloaded artifacts >> >> 2) No description of how to validate downloads >> >> 3) There is a link to nightly builds. >> That is not allowed on a public download page, as the builds >>> have > not >>> been >> voted on. >> >> 4) The paragraph introducing the binary artifact says: >> >> "In order to verify the release, we recommend that you >>> download > the >>
[jira] [Created] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: IgniteCheckedException: Cannot enable read-through (loader or store is not provided) for cache
Alexey Kukushkin created IGNITE-12898:
-
Summary: Server node with CacheStore fails to re-join the cluster:
IgniteCheckedException: Cannot enable read-through (loader or store is not
provided) for cache
Key: IGNITE-12898
URL: https://issues.apache.org/jira/browse/IGNITE-12898
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin
If a cache with external persistence is dynamically created on a non-affinity
node then the cache affinity node cannot join the cluster after restart.
h2. Repro Steps
# Run an "empty" Ignite node where no cache is going to be started
# Run a cache affinity node having the "ROLE" attribute set to "DATA"
# Create the cache from the "empty" node and use a Node Filter to limit the
cache to the "data" node. External persistence is configured for the cache.
# Restart the "data" node
h3. Actual Result
{{IgniteCheckedException: Cannot enable read-through (loader or store is not
provided) for cache}}
h2. Reproducer
h3. Reproducer.java
{code:java}
public class Reproducer {
@Test
public void test() throws Exception {
final String DB_URL = "jdbc:h2:mem:test";
final String ENTITY_NAME = "Person";
Function igniteCfgFactory = instanceName ->
new IgniteConfiguration()
.setIgniteInstanceName(instanceName)
.setDiscoverySpi(new TcpDiscoverySpi()
.setIpFinder(new
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);
// 1. Run an "empty" Ignite node where no cache is going to be started
try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", "");
Statement dbStmt = dbConn.createStatement();
Ignite emptyNode =
Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
// 2. Run a "Person" cache affinity node having the "ROLE"
attribute set to "DATA"
Map dataNodeAttrs = new HashMap<>(1);
dataNodeAttrs.put(DataNodeFilter.ATTR_NAME,
DataNodeFilter.ATTR_VAL);
Ignite dataNode =
Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));
// 3. Create the "Person" cache from the "empty" node and use a
Node Filter to limit the cache to the
// "data" node. External persistence to the "Person" table in H2 DB
is configured for the cache.
dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY
KEY, name varchar)");
CacheJdbcPojoStoreFactory igniteStoreFactory
= new CacheJdbcPojoStoreFactory<>();
igniteStoreFactory.setDataSourceFactory(() ->
JdbcConnectionPool.create(DB_URL, "sa", ""))
.setTypes(
new JdbcType()
.setCacheName(ENTITY_NAME)
.setDatabaseTable(ENTITY_NAME)
.setKeyType(Integer.class)
.setValueType(ENTITY_NAME)
.setKeyFields(new JdbcTypeField(java.sql.Types.INTEGER,
"id", Integer.class, "id"))
.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id",
Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name",
String.class, "name")
)
);
CacheConfiguration cacheCfg =
new CacheConfiguration(ENTITY_NAME)
.setCacheMode(CacheMode.REPLICATED)
.setCacheStoreFactory(igniteStoreFactory)
.setWriteThrough(true)
.setReadThrough(true)
.setNodeFilter(new DataNodeFilter());
emptyNode.createCache(cacheCfg).withKeepBinary();
// 4. Restart the "data" node
dataNode.close();
dataNode =
Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));
dataNode.close();
}
}
private static class DataNodeFilter implements IgnitePredicate
{
public static final String ATTR_NAME = "ROLE";
public static final String ATTR_VAL = "DATA";
@Override public boolean apply(ClusterNode node) {
Object role = node.attributes().get(ATTR_NAME);
return role != null && ATTR_VAL.equalsIgnoreCase(role.toString());
}
}
}
{code}
h3. build.gradle
{code:groovy}
dependencies {
compile group: 'org.apache.ignite', name: 'ignite-core', version: '2.8.0'
compile group: 'com.h2database', name: 'h2', version: '1.4.200'
testCompile group: 'junit', name: 'junit', version: '4.12'
}
{code}
h2. Workaround
Create dynamic caches only on the affinity nodes or use "static" caches defined
in ignite node configuration.
h2. Stack Trace
{code}
class
Re: [DISCUSSION] Pull-request checks on GitHub
Petr, I think it's doable. It has custom `install-jdk` script, so even the latest JDKs can be used. [1] https://github.com/sormuras/bach#install-jdksh On Tue, 14 Apr 2020 at 18:31, Petr Ivanov wrote: > > We do not need JDK10 — it is out of support already. > Instead, how about adding JDK14? > > > On 14 Apr 2020, at 17:30, Maxim Muzafarov wrote: > > > > Folks, > > > > I forgot to mention one more important thing of this tool. We can > > configure build and checks simultaneously for several JDK versions. > > > > jdk: > > - oraclejdk8 > > - openjdk10 > > - openjdk11 > > > > On Tue, 14 Apr 2020 at 17:17, Maxim Muzafarov wrote: > >> > >> Folks, > >> > >> +1 Travis-ci > >> > >> I see no disadvantages of having multiple CI tools due to: > >> - it's free for open-source and can be disabled at any time without > >> any consequences; > >> - it will free TeamCity from running builds on each PR and TC can > >> focus on tests execution; > >> - we can perform more sophisticated checks with this tool like a PR > >> title format (e.g. IGNITE-X: Sample) > >> > >> It seems the TC.Bot can also be integrated with GitHub checks via REST API > >> [1]. > >> > >> > >> I've checked locally the Ignite build procedure with travis-ci and > >> GitHub checks [2] and looks like everything is working fine. > >> Who can configure the similar things on Apache Ignite GitHub mirror? > >> Does anyone have such access rights? > >> > >> > >> [1] https://developer.github.com/v3/checks/runs/ > >> [2] https://github.com/Mmuzaf/ignite/pull/1/checks?check_run_id=584537955 > >> > >> On Tue, 14 Apr 2020 at 10:37, Nikolay Izhikov wrote: > >>> > On another hand, it seems weird to have both TeamCity and Travis > >>> > >>> And don’t forget MTCGA bot! > >>> > >>> > 14 апр. 2020 г., в 10:23, Pavel Tupitsyn > написал(а): > > We should have PR checks for sure. > > On one hand, I agree with Denis: > - Travis is very easy to set up in GitHub > - Config file (travis.yml) is stored in git, which is great > > On another hand, it seems weird to have both TeamCity and Travis. > Thoughts? > > On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > > > Hello! > > > > I have seen projects with Travis-ci they look cool. > > I think Travis-ci is a good solution. > > > > вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov > > >> : > > > >> Maxim, > >> > >> Good idea. I'd add a license check as well. > >> > >> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov > > wrote: > >> > >>> Igniters, > >>> > >>> It's really `must-have` feature for me to enable Apache Ignite > >>> pull-request status checks on GitHub. Currently we don't have any of > >>> them. The most obvious check for each pull-request is: > >>> - build the source code and check code-style violations; > >>> > >>> This will give us some advantages. For instance: > >>> 1. Each PR even a very simple (not require tests execution) will be > >>> checked by checkstyle and for compile errors. > >>> 2. Developers can be get notified earlier if checkstyle has been > >>> violated in their PRs. > >>> > >>> To achieve this we can do the following: > >>> 1. Configure our TeamCity integration with the Ignite GitHub > >>> repository and PR build. It seems it is possible [2]. > >>> 2. Use Travis-ci which is free for open-source projects and also has > >>> an integration with GitHub checks [1]. > >>> > >>> > >>> What do you think? > >>> What options will be the best for us? > >>> > >>> [1] > >>> > >> > > https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > >>> [2] > >>> > >> > > https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > >>> > >> > >> > >> -- > >> Best regards, > >> Andrey V. Mashenkov > >> > > > >>> >
Re: [DISCUSSION] Pull-request checks on GitHub
We do not need JDK10 — it is out of support already. Instead, how about adding JDK14? > On 14 Apr 2020, at 17:30, Maxim Muzafarov wrote: > > Folks, > > I forgot to mention one more important thing of this tool. We can > configure build and checks simultaneously for several JDK versions. > > jdk: > - oraclejdk8 > - openjdk10 > - openjdk11 > > On Tue, 14 Apr 2020 at 17:17, Maxim Muzafarov wrote: >> >> Folks, >> >> +1 Travis-ci >> >> I see no disadvantages of having multiple CI tools due to: >> - it's free for open-source and can be disabled at any time without >> any consequences; >> - it will free TeamCity from running builds on each PR and TC can >> focus on tests execution; >> - we can perform more sophisticated checks with this tool like a PR >> title format (e.g. IGNITE-X: Sample) >> >> It seems the TC.Bot can also be integrated with GitHub checks via REST API >> [1]. >> >> >> I've checked locally the Ignite build procedure with travis-ci and >> GitHub checks [2] and looks like everything is working fine. >> Who can configure the similar things on Apache Ignite GitHub mirror? >> Does anyone have such access rights? >> >> >> [1] https://developer.github.com/v3/checks/runs/ >> [2] https://github.com/Mmuzaf/ignite/pull/1/checks?check_run_id=584537955 >> >> On Tue, 14 Apr 2020 at 10:37, Nikolay Izhikov wrote: >>> On another hand, it seems weird to have both TeamCity and Travis >>> >>> And don’t forget MTCGA bot! >>> >>> 14 апр. 2020 г., в 10:23, Pavel Tupitsyn написал(а): We should have PR checks for sure. On one hand, I agree with Denis: - Travis is very easy to set up in GitHub - Config file (travis.yml) is stored in git, which is great On another hand, it seems weird to have both TeamCity and Travis. Thoughts? On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > Hello! > > I have seen projects with Travis-ci they look cool. > I think Travis-ci is a good solution. > > вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov > : > >> Maxim, >> >> Good idea. I'd add a license check as well. >> >> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov > wrote: >> >>> Igniters, >>> >>> It's really `must-have` feature for me to enable Apache Ignite >>> pull-request status checks on GitHub. Currently we don't have any of >>> them. The most obvious check for each pull-request is: >>> - build the source code and check code-style violations; >>> >>> This will give us some advantages. For instance: >>> 1. Each PR even a very simple (not require tests execution) will be >>> checked by checkstyle and for compile errors. >>> 2. Developers can be get notified earlier if checkstyle has been >>> violated in their PRs. >>> >>> To achieve this we can do the following: >>> 1. Configure our TeamCity integration with the Ignite GitHub >>> repository and PR build. It seems it is possible [2]. >>> 2. Use Travis-ci which is free for open-source projects and also has >>> an integration with GitHub checks [1]. >>> >>> >>> What do you think? >>> What options will be the best for us? >>> >>> [1] >>> >> > https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com >>> [2] >>> >> > https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ >>> >> >> >> -- >> Best regards, >> Andrey V. Mashenkov >> > >>>
Re: [DISCUSSION] Pull-request checks on GitHub
Folks, I forgot to mention one more important thing of this tool. We can configure build and checks simultaneously for several JDK versions. jdk: - oraclejdk8 - openjdk10 - openjdk11 On Tue, 14 Apr 2020 at 17:17, Maxim Muzafarov wrote: > > Folks, > > +1 Travis-ci > > I see no disadvantages of having multiple CI tools due to: > - it's free for open-source and can be disabled at any time without > any consequences; > - it will free TeamCity from running builds on each PR and TC can > focus on tests execution; > - we can perform more sophisticated checks with this tool like a PR > title format (e.g. IGNITE-X: Sample) > > It seems the TC.Bot can also be integrated with GitHub checks via REST API > [1]. > > > I've checked locally the Ignite build procedure with travis-ci and > GitHub checks [2] and looks like everything is working fine. > Who can configure the similar things on Apache Ignite GitHub mirror? > Does anyone have such access rights? > > > [1] https://developer.github.com/v3/checks/runs/ > [2] https://github.com/Mmuzaf/ignite/pull/1/checks?check_run_id=584537955 > > On Tue, 14 Apr 2020 at 10:37, Nikolay Izhikov wrote: > > > > > On another hand, it seems weird to have both TeamCity and Travis > > > > And don’t forget MTCGA bot! > > > > > > > 14 апр. 2020 г., в 10:23, Pavel Tupitsyn > > > написал(а): > > > > > > We should have PR checks for sure. > > > > > > On one hand, I agree with Denis: > > > - Travis is very easy to set up in GitHub > > > - Config file (travis.yml) is stored in git, which is great > > > > > > On another hand, it seems weird to have both TeamCity and Travis. > > > Thoughts? > > > > > > On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > > > > > >> Hello! > > >> > > >> I have seen projects with Travis-ci they look cool. > > >> I think Travis-ci is a good solution. > > >> > > >> вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov > >>> : > > >> > > >>> Maxim, > > >>> > > >>> Good idea. I'd add a license check as well. > > >>> > > >>> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov > > >> wrote: > > >>> > > Igniters, > > > > It's really `must-have` feature for me to enable Apache Ignite > > pull-request status checks on GitHub. Currently we don't have any of > > them. The most obvious check for each pull-request is: > > - build the source code and check code-style violations; > > > > This will give us some advantages. For instance: > > 1. Each PR even a very simple (not require tests execution) will be > > checked by checkstyle and for compile errors. > > 2. Developers can be get notified earlier if checkstyle has been > > violated in their PRs. > > > > To achieve this we can do the following: > > 1. Configure our TeamCity integration with the Ignite GitHub > > repository and PR build. It seems it is possible [2]. > > 2. Use Travis-ci which is free for open-source projects and also has > > an integration with GitHub checks [1]. > > > > > > What do you think? > > What options will be the best for us? > > > > [1] > > > > >>> > > >> https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > > [2] > > > > >>> > > >> https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > > > > >>> > > >>> > > >>> -- > > >>> Best regards, > > >>> Andrey V. Mashenkov > > >>> > > >> > >
[jira] [Created] (IGNITE-12897) Add .NET api to enabling SQL indexing for existing cache.
Ivan Daschinskiy created IGNITE-12897: - Summary: Add .NET api to enabling SQL indexing for existing cache. Key: IGNITE-12897 URL: https://issues.apache.org/jira/browse/IGNITE-12897 Project: Ignite Issue Type: Bug Components: platforms Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Add .NET api to enabling SQL indexing for existing cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Pull-request checks on GitHub
Folks, +1 Travis-ci I see no disadvantages of having multiple CI tools due to: - it's free for open-source and can be disabled at any time without any consequences; - it will free TeamCity from running builds on each PR and TC can focus on tests execution; - we can perform more sophisticated checks with this tool like a PR title format (e.g. IGNITE-X: Sample) It seems the TC.Bot can also be integrated with GitHub checks via REST API [1]. I've checked locally the Ignite build procedure with travis-ci and GitHub checks [2] and looks like everything is working fine. Who can configure the similar things on Apache Ignite GitHub mirror? Does anyone have such access rights? [1] https://developer.github.com/v3/checks/runs/ [2] https://github.com/Mmuzaf/ignite/pull/1/checks?check_run_id=584537955 On Tue, 14 Apr 2020 at 10:37, Nikolay Izhikov wrote: > > > On another hand, it seems weird to have both TeamCity and Travis > > And don’t forget MTCGA bot! > > > > 14 апр. 2020 г., в 10:23, Pavel Tupitsyn написал(а): > > > > We should have PR checks for sure. > > > > On one hand, I agree with Denis: > > - Travis is very easy to set up in GitHub > > - Config file (travis.yml) is stored in git, which is great > > > > On another hand, it seems weird to have both TeamCity and Travis. > > Thoughts? > > > > On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > > > >> Hello! > >> > >> I have seen projects with Travis-ci they look cool. > >> I think Travis-ci is a good solution. > >> > >> вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov >>> : > >> > >>> Maxim, > >>> > >>> Good idea. I'd add a license check as well. > >>> > >>> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov > >> wrote: > >>> > Igniters, > > It's really `must-have` feature for me to enable Apache Ignite > pull-request status checks on GitHub. Currently we don't have any of > them. The most obvious check for each pull-request is: > - build the source code and check code-style violations; > > This will give us some advantages. For instance: > 1. Each PR even a very simple (not require tests execution) will be > checked by checkstyle and for compile errors. > 2. Developers can be get notified earlier if checkstyle has been > violated in their PRs. > > To achieve this we can do the following: > 1. Configure our TeamCity integration with the Ignite GitHub > repository and PR build. It seems it is possible [2]. > 2. Use Travis-ci which is free for open-source projects and also has > an integration with GitHub checks [1]. > > > What do you think? > What options will be the best for us? > > [1] > > >>> > >> https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > [2] > > >>> > >> https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > > >>> > >>> > >>> -- > >>> Best regards, > >>> Andrey V. Mashenkov > >>> > >> >
[jira] [Created] (IGNITE-12896) excludeNeighbors=true breaks zone-awareness
Zaar Hai created IGNITE-12896: - Summary: excludeNeighbors=true breaks zone-awareness Key: IGNITE-12896 URL: https://issues.apache.org/jira/browse/IGNITE-12896 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Zaar Hai Good day, If I configure node config as in the official [example |[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html]] but also set excludeNeighbors to true, then zone-aware partition distribution simply doesn't work. No errors or warnings that found - it is just does not work. >From documentation it's not clear (at least to me) that excludeNeighbors=true >has such a critical implication on zone-awareness info. From what is sounds, >zone-awareness is an extension of excludeNeighbors. I think this behavour should be fixed or at least documented with big red signs. As it's now, it resulted in several days of my time batting with zone-aware setup. There are more details here in this StackOverflow question: [https://stackoverflow.com/questions/61062929/apache-ignite-zonerack-aware-parititons/61189356#61189356] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12895) AlreadyClosedException: this IndexReader is closed in Cluster Query
André Schäfer created IGNITE-12895:
--
Summary: AlreadyClosedException: this IndexReader is closed in
Cluster Query
Key: IGNITE-12895
URL: https://issues.apache.org/jira/browse/IGNITE-12895
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.6
Reporter: André Schäfer
A simple text query like
{code:java}
var query = new TextQuery(type,
parse(search.getQuery())).setPageSize(search.getMaxResults());
try (final var cursor = cache.getCache(cacheName).query(query)) {
return stream(cursor).map(Entry::getValue).collect(toList());
}
{code}
in our 6 node setup produces in 3-5 log messages on ERROR level but seem to
deliver a correct result set anyway. It seems that the "remote" searches may be
performed on a closed index reader for some unknown reason.
{code}
Failed to run query [qry=GridCacheQueryInfo [loc=false, trans=null,
rdc=null, qry=GridCacheQueryAdapter [type=TEXT, clsName=Person,
clause=(dietmar)^20.0 dietmar~1, filter=null, transform=null, part=null,
incMeta=false, metrics=null, pageSize=1024, timeout=0, incBackups=false,
forceLocal=false, dedup=false, prj=null, keepBinary=false,
subjId=06170e29-2b5f-44e3-a0ae-35eceef94971, taskHash=0, mvccSnapshot=null],
locFut=null, sndId=06170e29-2b5f-44e3-a0ae-35eceef94971, reqId=71340905,
incMeta=false, all=false], node=3821e3d1-11b7-49c4-af19-df0fd32066e2]
{code}
{code}
org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:257)
at
org.apache.lucene.index.BaseCompositeReader.document(BaseCompositeReader.java:116)
at org.apache.lucene.index.IndexReader.document(IndexReader.java:349)
at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:316)
at
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.findNext(GridLuceneIndex.java:381)
at
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.onNext(GridLuceneIndex.java:413)
at
org.apache.ignite.internal.processors.query.h2.opt.GridLuceneIndex$It.onNext(GridLuceneIndex.java:308)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1144)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:234)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] Pull-request checks on GitHub
> On another hand, it seems weird to have both TeamCity and Travis And don’t forget MTCGA bot! > 14 апр. 2020 г., в 10:23, Pavel Tupitsyn написал(а): > > We should have PR checks for sure. > > On one hand, I agree with Denis: > - Travis is very easy to set up in GitHub > - Config file (travis.yml) is stored in git, which is great > > On another hand, it seems weird to have both TeamCity and Travis. > Thoughts? > > On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > >> Hello! >> >> I have seen projects with Travis-ci they look cool. >> I think Travis-ci is a good solution. >> >> вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov >> : >> >>> Maxim, >>> >>> Good idea. I'd add a license check as well. >>> >>> On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov >> wrote: >>> Igniters, It's really `must-have` feature for me to enable Apache Ignite pull-request status checks on GitHub. Currently we don't have any of them. The most obvious check for each pull-request is: - build the source code and check code-style violations; This will give us some advantages. For instance: 1. Each PR even a very simple (not require tests execution) will be checked by checkstyle and for compile errors. 2. Developers can be get notified earlier if checkstyle has been violated in their PRs. To achieve this we can do the following: 1. Configure our TeamCity integration with the Ignite GitHub repository and PR build. It seems it is possible [2]. 2. Use Travis-ci which is free for open-source projects and also has an integration with GitHub checks [1]. What do you think? What options will be the best for us? [1] >>> >> https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com [2] >>> >> https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ >>> >>> >>> -- >>> Best regards, >>> Andrey V. Mashenkov >>> >>
Re: [DISCUSSION] Pull-request checks on GitHub
We should have PR checks for sure. On one hand, I agree with Denis: - Travis is very easy to set up in GitHub - Config file (travis.yml) is stored in git, which is great On another hand, it seems weird to have both TeamCity and Travis. Thoughts? On Tue, Apr 14, 2020 at 10:16 AM Denis Garus wrote: > Hello! > > I have seen projects with Travis-ci they look cool. > I think Travis-ci is a good solution. > > вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov >: > > > Maxim, > > > > Good idea. I'd add a license check as well. > > > > On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov > wrote: > > > > > Igniters, > > > > > > It's really `must-have` feature for me to enable Apache Ignite > > > pull-request status checks on GitHub. Currently we don't have any of > > > them. The most obvious check for each pull-request is: > > > - build the source code and check code-style violations; > > > > > > This will give us some advantages. For instance: > > > 1. Each PR even a very simple (not require tests execution) will be > > > checked by checkstyle and for compile errors. > > > 2. Developers can be get notified earlier if checkstyle has been > > > violated in their PRs. > > > > > > To achieve this we can do the following: > > > 1. Configure our TeamCity integration with the Ignite GitHub > > > repository and PR build. It seems it is possible [2]. > > > 2. Use Travis-ci which is free for open-source projects and also has > > > an integration with GitHub checks [1]. > > > > > > > > > What do you think? > > > What options will be the best for us? > > > > > > [1] > > > > > > https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > > > [2] > > > > > > https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > >
Re: [DISCUSSION] Pull-request checks on GitHub
Hello! I have seen projects with Travis-ci they look cool. I think Travis-ci is a good solution. вт, 14 апр. 2020 г. в 10:00, Andrey Mashenkov : > Maxim, > > Good idea. I'd add a license check as well. > > On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov wrote: > > > Igniters, > > > > It's really `must-have` feature for me to enable Apache Ignite > > pull-request status checks on GitHub. Currently we don't have any of > > them. The most obvious check for each pull-request is: > > - build the source code and check code-style violations; > > > > This will give us some advantages. For instance: > > 1. Each PR even a very simple (not require tests execution) will be > > checked by checkstyle and for compile errors. > > 2. Developers can be get notified earlier if checkstyle has been > > violated in their PRs. > > > > To achieve this we can do the following: > > 1. Configure our TeamCity integration with the Ignite GitHub > > repository and PR build. It seems it is possible [2]. > > 2. Use Travis-ci which is free for open-source projects and also has > > an integration with GitHub checks [1]. > > > > > > What do you think? > > What options will be the best for us? > > > > [1] > > > https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > > [2] > > > https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > > > > > -- > Best regards, > Andrey V. Mashenkov >
Re: [DISCUSSION] Pull-request checks on GitHub
Maxim, Good idea. I'd add a license check as well. On Tue, Apr 14, 2020 at 2:14 AM Maxim Muzafarov wrote: > Igniters, > > It's really `must-have` feature for me to enable Apache Ignite > pull-request status checks on GitHub. Currently we don't have any of > them. The most obvious check for each pull-request is: > - build the source code and check code-style violations; > > This will give us some advantages. For instance: > 1. Each PR even a very simple (not require tests execution) will be > checked by checkstyle and for compile errors. > 2. Developers can be get notified earlier if checkstyle has been > violated in their PRs. > > To achieve this we can do the following: > 1. Configure our TeamCity integration with the Ignite GitHub > repository and PR build. It seems it is possible [2]. > 2. Use Travis-ci which is free for open-source projects and also has > an integration with GitHub checks [1]. > > > What do you think? > What options will be the best for us? > > [1] > https://blog.travis-ci.com/2018-05-07-announcing-support-for-github-checks-api-on-travis-ci-com > [2] > https://himynameistim.com/2018/01/16/adding-build-statuses-to-pull-requests-with-teamcity-and-github/ > -- Best regards, Andrey V. Mashenkov
