[jira] [Created] (IGNITE-11159) Collections of 'start-on-join' caches and 'init-caches' should be filtered
Sergey Chugunov created IGNITE-11159: Summary: Collections of 'start-on-join' caches and 'init-caches' should be filtered Key: IGNITE-11159 URL: https://issues.apache.org/jira/browse/IGNITE-11159 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Broken layout of Ignite javadoc on web
Hi,
Continuation of the story. I build javadocs locally and checked how it
renders with manually added images. Unfortunately there are several
visible artifacts. I guess the reason here is that stylesheet and
images was suitable for an older version of javadoc maven plugin but
not for a newer one.
Also I noticed that style used by Ignite is similar to Java 7 docs
[1]. Different style is used since Java 8 [2]. And it looks like by
default maven javadoc plugin today builds similar pages. You can see
an example of Ignite javadoc built with default style [3].
So, perhaps we can use a default style for our documentation, cannot we?
[1] https://docs.oracle.com/javase/7/docs/api/java/util/BitSet.html
[2]
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/BitSet.html
[3] https://gist.github.com/pavlukhin/c627b31c09e4f1ae7bd04f11bafed040
пн, 24 дек. 2018 г. в 17:34, Павлухин Иван :
>
> Hi,
>
> Mentioned javadoc.css references to some image resources. They present
> for 2.3.0 release [1]. But similar url returns 404 for 2.7.0 [2]. Who
> knows how to upload resources?
>
> [1] https://ignite.apache.org/releases/2.3.0/javadoc/resources
> [2] https://ignite.apache.org/releases/2.7.0/javadoc/resources
>
> пн, 17 дек. 2018 г. в 16:38, Павлухин Иван :
>
> >
> > Dmitriy,
> >
> > Yep, it looks like the problem is inside assembly/docfiles/javadoc.css
> >
> > I will try to dig into some time later on a spare time. Of course, if
> > nobody fixes the problem earlier.
> > пн, 17 дек. 2018 г. в 15:18, Dmitriy Pavlov :
> > >
> > > I see the same, browsers checked: Edge & Chrome. I guess it is not a
> > > layout
> > > is broken, but a style missing.
> > >
> > > Unfortunately, I don't know how to fix. Probably we should start research
> > > from ignite/pom.xml:191
> > >
> > > ${basedir}/assembly/docfiles/javadoc.css
> > >
> > >
> > > пн, 17 дек. 2018 г. в 14:32, Павлухин Иван :
> > >
> > > > Hi,
> > > >
> > > > I noticed that Ignite javadoc layout on web for latest versions has
> > > > some problems. For example, I see no links near the "Class" at heading
> > > > of the page [1]. Here is a screenshot [2]. Do you see the same?
> > > >
> > > > I was able to build javadoc on my machine. With current configuration
> > > > I see the same broken layout. After using commenting out customized
> > > > style sheet configuration (referring to assembly/docfiles/javadoc.css)
> > > > I was able to obtain an html which renders fine for me.
> > > >
> > > > Can anyone suggest a simple solution for this?
> > > >
> > > > [1]
> > > > https://ignite.apache.org/releases/2.7.0/javadoc/org/apache/ignite/cache/eviction/EvictionPolicy.html
> > > > [2]
> > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1b257ad73f81cb4698f6105a9d1646295ba55795/javadoc_layout.png
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
--
Best regards,
Ivan Pavlukhin
[MTCGA]: new failures in builds [2956048] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New stable failure of a flaky test in master GridCacheRebalancingPartitionDistributionTest.testRollingRestart https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3585467642776655680&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=874253 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 11:17:52 31-01-2019
[jira] [Created] (IGNITE-11160) SQL: Create light-weight row for read-only rows
Vladimir Ozerov created IGNITE-11160:
Summary: SQL: Create light-weight row for read-only rows
Key: IGNITE-11160
URL: https://issues.apache.org/jira/browse/IGNITE-11160
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
In order to minimize memory overhead during query execution we can create
simplified version of {{GridH2KeyValueRowOnheap}} which will not hold reference
to original row. Also we can remove value cache as it is never used during
SELECT execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Does KeystoreEncryptionSpi have problem with size calculation?
Hi, I have been trying to solve a problem with calculation size for encryption mode, it's ticket IGNITE-11129. But I found an additional place for wrong behavior. I'm confused, Is it fine or wrong? Look at *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. Should we use this code: ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; If yes, I'll fix it.
Re: .Net docs need to be aligned with Java - dev review needed!
Hello Igniters, It seems that https://apacheignite-net.readme.io/docs/performance-tips is outdated as well. In particular, https://apacheignite-net.readme.io/docs/performance-tips#section-tune-cache-start-size does not make sense as of Apache Ignite 2.x. I added a comment to the mentioned jira ticket. Thanks, S. чт, 31 янв. 2019 г. в 08:22, Denis Magda : > Thanks, Stan for catching that. > > Expiration and eviction policies are not aligned with Java counterparts as > well: > https://apacheignite-net.readme.io/docs/eviction-policies > https://apacheignite-net.readme.io/docs/expiry-policies > > In Java we explain how it works for the new off-heap memory and on-heap > Java cache, while .Net docs are based on no longer supported Ignite 1.x > memory architecture. > > > - > Denis > > > On Wed, Jan 30, 2019 at 4:34 AM Stanislav Lukyanov > > wrote: > > > Hi Igniters, > > > > I see that some parts of the .Net docs on readme.io are outdated > compared > > to the Java docs. > > E.g. take off-heap memory page > > https://apacheignite-net.readme.io/docs/off-heap-memory - the info there > > is for Ignite 1.x > > while in 2.x we don’t have all these tiered modes. > > Such discrepancies are very misleading to users, especially new ones. > > > > I’ve filed a ticket https://issues.apache.org/jira/browse/IGNITE-10887 > > for Documentation. > > Artem Budnikov agreed to do the updates on readme.io, but he needs the > > list of the documentation parts that need changing. > > > > All Igniters and especially .Net users, > > Please take a moment to go over the .Net docs at > > https://apacheignite-net.readme.io/docs/, > > page by page, and if you see anything that is obviously > > wrong/false/misleading, please add that as a comment to the > > https://issues.apache.org/jira/browse/IGNITE-10887. > > If you review any part of the docs, please let us know here so that we > > know which parts are covered. > > > > I would suggest we focus on false/outdated information only. > > If some part of the docs is not clear enough that’s a different issue. > > Here I’d like to only collect the list of the sections with things that > are > > not applicable to Ignite 2.7. > > > > Thanks, > > Stan > > >
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Hi Maxim, why do you think that data size can be divided to cipher block size with 0 remainder. I used to think that page size 4096 is always divisible by a usual block cipher block size, e.g 32, 16 or 8 bytes чт, 31 янв. 2019 г. в 13:11, Максим Степачёв : > Hi, I have been trying to solve a problem with calculation size for > encryption mode, it's ticket IGNITE-11129. But I found an additional place > for wrong behavior. I'm confused, Is it fine or wrong? Look at > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as > > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. > Should we use this code: > > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > If yes, I'll fix it. >
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Dmitriy Pavlov, Your statement about page size is true. But our case about plainSize of serialized record in bytes. This method calculates it: plainSize(WALRecord record). For example, if you look in this method, you will see DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 + 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number. чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov : > Hi Maxim, why do you think that data size can be divided to cipher block > size with 0 remainder. > > I used to think that page size 4096 is always divisible by a usual block > cipher block size, e.g 32, 16 or 8 bytes > > чт, 31 янв. 2019 г. в 13:11, Максим Степачёв : > > > Hi, I have been trying to solve a problem with calculation size for > > encryption mode, it's ticket IGNITE-11129. But I found an additional > place > > for wrong behavior. I'm confused, Is it fine or wrong? Look at > > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as > > > > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > > > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. > > Should we use this code: > > > > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > > > If yes, I'll fix it. > > >
[jira] [Created] (IGNITE-11161) ClientCache get by user defined key returns null
Sergey Antonov created IGNITE-11161:
---
Summary: ClientCache get by user defined key returns null
Key: IGNITE-11161
URL: https://issues.apache.org/jira/browse/IGNITE-11161
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.7
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
Scenario:
* Start server node with predefined cache and activate cluster.
* Connect thin java client to cluster
* Put entry to the cache with user defined key (custom class) from server node.
* Try get value from thin client by the same key.
Expected:
* Returns putted value
Actual:
* Returns null
Reproducer:
{code:java}
import java.util.Objects;
import org.apache.ignite.Ignition;
import org.apache.ignite.client.IgniteClient;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.ClientConfiguration;
import org.apache.ignite.configuration.ClientConnectorConfiguration;
import org.apache.ignite.configuration.DataStorageConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.internal.util.typedef.internal.S;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.JUnit4;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
@RunWith(JUnit4.class)
public class ClientTestGet extends GridCommonAbstractTest {
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(new ClientConnectorConfiguration())
.setDataStorageConfiguration(new DataStorageConfiguration())
.setCacheConfiguration(new
CacheConfiguration().setName(DEFAULT_CACHE_NAME).setWriteSynchronizationMode(FULL_SYNC));
}
@Override protected void beforeTest() throws Exception {
super.beforeTest();
cleanPersistenceDir();
}
@Test
public void testGet() throws Exception {
IgniteConfiguration serverCfg = getConfiguration("server");
IgniteEx server = startGrid(serverCfg);
server.cluster().active(true);
IgniteClient client = Ignition.startClient(
new ClientConfiguration().setAddresses("127.0.0.1:" +
serverCfg.getClientConnectorConfiguration().getPort())
);
server.cache(DEFAULT_CACHE_NAME).put(new Key(0), 0);
Object serverVal = server.cache(DEFAULT_CACHE_NAME).get(new Key(0));
Object clientVal = client.cache(DEFAULT_CACHE_NAME).get(new Key(0));
assertEquals(serverVal, clientVal);
}
private static class Key {
private final int i;
private Key(int i) {
this.i = i;
}
/** {@inheritDoc} */
@Override public boolean equals(Object o) {
if (this == o)
return true;
if (o == null || getClass() != o.getClass())
return false;
return i == ((Key)o).i;
}
/** {@inheritDoc} */
@Override public int hashCode() {
return Objects.hash(i);
}
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Key.class, this);
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Hello, Maxim. > IGNITE-11129 Do we have reproducer for this ticket? WalRecord will be encrypted only if record class implements WalRecordCacheGroupAwarei.e it contains some cache data that should be protected with encryption. Please, look into private boolean needEncryption(WALRecord rec). SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not encryption would be applied for this types of records. I think we should close IGNITE-11129 as invalid. > Should we use this code: Please, explain, why do you think so? Do you find some bug? Can you send a reproducer? You can find details of encrypted data size calculation in AES algorithm description. чт, 31 янв. 2019 г. в 15:24, Максим Степачёв : > Dmitriy Pavlov, > > Your statement about page size is true. But our case about plainSize of > serialized record in bytes. This method calculates it: plainSize(WALRecord > record). For example, if you look in this method, you will see > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 + > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number. > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov : > >> Hi Maxim, why do you think that data size can be divided to cipher block >> size with 0 remainder. >> >> I used to think that page size 4096 is always divisible by a usual block >> cipher block size, e.g 32, 16 or 8 bytes >> >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв > >: >> >> > Hi, I have been trying to solve a problem with calculation size for >> > encryption mode, it's ticket IGNITE-11129. But I found an additional >> place >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as >> > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; >> > >> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. >> > Should we use this code: >> > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; >> > >> > If yes, I'll fix it. >> > >> >
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Nikolay, I see. We should close IGNITE-11129 as invalid. I'm going to ask the reporter, what he means. > Please, explain, why do you think so? I answered to Dmitriy Pavlov with explaining. In short, your method encryptedSize(int dataSize) returns the *"*wrong result*"* when I call it with dataSize = 20. I suppose the AES algorithm work with blocks by 16 bytes for encryption data + 2 bytes for padding in AES_WITH_PADDING mode. The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) * 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine? чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov : > Hello, Maxim. > > > IGNITE-11129 > > Do we have reproducer for this ticket? > WalRecord will be encrypted only if record class > implements WalRecordCacheGroupAwarei.e it contains some cache data that > should be protected with encryption. > Please, look into private boolean needEncryption(WALRecord rec). > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not > encryption would be applied for this types of records. > > I think we should close IGNITE-11129 as invalid. > > > Should we use this code: > > Please, explain, why do you think so? > Do you find some bug? > Can you send a reproducer? > > You can find details of encrypted data size calculation in AES algorithm > description. > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв : > > > Dmitriy Pavlov, > > > > Your statement about page size is true. But our case about plainSize of > > serialized record in bytes. This method calculates it: > plainSize(WALRecord > > record). For example, if you look in this method, you will see > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 > + > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number. > > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov : > > > >> Hi Maxim, why do you think that data size can be divided to cipher block > >> size with 0 remainder. > >> > >> I used to think that page size 4096 is always divisible by a usual block > >> cipher block size, e.g 32, 16 or 8 bytes > >> > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв < > maksim.stepac...@gmail.com > >> >: > >> > >> > Hi, I have been trying to solve a problem with calculation size for > >> > encryption mode, it's ticket IGNITE-11129. But I found an additional > >> place > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as > >> > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > >> > > >> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. > >> > Should we use this code: > >> > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > >> > > >> > If yes, I'll fix it. > >> > > >> > > >
[jira] [Created] (IGNITE-11162) SQL: Print a warning if SQL index inline size is overly large
Ilya Kasnacheev created IGNITE-11162: Summary: SQL: Print a warning if SQL index inline size is overly large Key: IGNITE-11162 URL: https://issues.apache.org/jira/browse/IGNITE-11162 Project: Ignite Issue Type: New Feature Components: sql Affects Versions: 2.7 Reporter: Ilya Kasnacheev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Maxim, > I suppose the AES algorithm work with blocks by 16 bytes for encryption data + 2 bytes for padding in AES_WITH_PADDING mode Why do you make this conclusion? Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV and for padding info. You can find sanity check in KeystoreEncryptionSpiSelfTest. Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt which check the case you described. чт, 31 янв. 2019 г. в 17:08, Максим Степачёв : > > Nikolay, > I see. We should close IGNITE-11129 as invalid. I'm going to ask the > reporter, what he means. > > > Please, explain, why do you think so? > I answered to Dmitriy Pavlov with explaining. > > In short, your method encryptedSize(int dataSize) returns the *"*wrong > result*"* when I call it with dataSize = 20. > I suppose the AES algorithm work with blocks by 16 bytes for > encryption data + 2 bytes for padding in AES_WITH_PADDING mode. > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) * > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine? > > > > > > > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov : > > > Hello, Maxim. > > > > > IGNITE-11129 > > > > Do we have reproducer for this ticket? > > WalRecord will be encrypted only if record class > > implements WalRecordCacheGroupAwarei.e it contains some cache data that > > should be protected with encryption. > > Please, look into private boolean needEncryption(WALRecord rec). > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not > > encryption would be applied for this types of records. > > > > I think we should close IGNITE-11129 as invalid. > > > > > Should we use this code: > > > > Please, explain, why do you think so? > > Do you find some bug? > > Can you send a reproducer? > > > > You can find details of encrypted data size calculation in AES algorithm > > description. > > > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв : > > > > > Dmitriy Pavlov, > > > > > > Your statement about page size is true. But our case about plainSize of > > > serialized record in bytes. This method calculates it: > > plainSize(WALRecord > > > record). For example, if you look in this method, you will see > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 > > + > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number. > > > > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov : > > > > > >> Hi Maxim, why do you think that data size can be divided to cipher block > > >> size with 0 remainder. > > >> > > >> I used to think that page size 4096 is always divisible by a usual block > > >> cipher block size, e.g 32, 16 or 8 bytes > > >> > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв < > > maksim.stepac...@gmail.com > > >> >: > > >> > > >> > Hi, I have been trying to solve a problem with calculation size for > > >> > encryption mode, it's ticket IGNITE-11129. But I found an additional > > >> place > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as > > >> > > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > >> > > > >> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ. > > >> > Should we use this code: > > >> > > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > >> > > > >> > If yes, I'll fix it. > > >> > > > >> > > > > >
[jira] [Created] (IGNITE-11163) [ML] Add hart beat tracker to DistributedInfModel
Anton Dmitriev created IGNITE-11163: --- Summary: [ML] Add hart beat tracker to DistributedInfModel Key: IGNITE-11163 URL: https://issues.apache.org/jira/browse/IGNITE-11163 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Assignee: Anton Dmitriev Fix For: 2.8 Currently we have DistributedInfModel that allocates resources across the cluster and relies on close() method to release them (it implements AutoCloseable). It works well in case client node works correctly. If it doesn't resources might stay allocated and so that we'll get a memory leak. To mitigate this risk it's proposed to add hart beat mechanism that will track if client is alive or not from server (service) side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Nikolay, It's my mistake. You're right. Thanks for answering. чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov : > Maxim, > > > I suppose the AES algorithm work with blocks by 16 bytes for encryption > data + 2 bytes for padding in AES_WITH_PADDING mode > > Why do you make this conclusion? > > Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV and > for padding info. > You can find sanity check in KeystoreEncryptionSpiSelfTest. > Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt > which check the case you described. > > чт, 31 янв. 2019 г. в 17:08, Максим Степачёв : > > > > Nikolay, > > I see. We should close IGNITE-11129 as invalid. I'm going to ask the > > reporter, what he means. > > > > > Please, explain, why do you think so? > > I answered to Dmitriy Pavlov with explaining. > > > > In short, your method encryptedSize(int dataSize) returns the *"*wrong > > result*"* when I call it with dataSize = 20. > > I suppose the AES algorithm work with blocks by 16 bytes for > > encryption data + 2 bytes for padding in AES_WITH_PADDING mode. > > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) * > > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine? > > > > > > > > > > > > > > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov : > > > > > Hello, Maxim. > > > > > > > IGNITE-11129 > > > > > > Do we have reproducer for this ticket? > > > WalRecord will be encrypted only if record class > > > implements WalRecordCacheGroupAwarei.e it contains some cache data that > > > should be protected with encryption. > > > Please, look into private boolean needEncryption(WALRecord rec). > > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not > > > encryption would be applied for this types of records. > > > > > > I think we should close IGNITE-11129 as invalid. > > > > > > > Should we use this code: > > > > > > Please, explain, why do you think so? > > > Do you find some bug? > > > Can you send a reproducer? > > > > > > You can find details of encrypted data size calculation in AES > algorithm > > > description. > > > > > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв < > maksim.stepac...@gmail.com > >: > > > > > > > Dmitriy Pavlov, > > > > > > > > Your statement about page size is true. But our case about plainSize > of > > > > serialized record in bytes. This method calculates it: > > > plainSize(WALRecord > > > > record). For example, if you look in this method, you will see > > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum > of: 4 > > > + > > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary > number. > > > > > > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov : > > > > > > > >> Hi Maxim, why do you think that data size can be divided to cipher > block > > > >> size with 0 remainder. > > > >> > > > >> I used to think that page size 4096 is always divisible by a usual > block > > > >> cipher block size, e.g 32, 16 or 8 bytes > > > >> > > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв < > > > maksim.stepac...@gmail.com > > > >> >: > > > >> > > > >> > Hi, I have been trying to solve a problem with calculation size > for > > > >> > encryption mode, it's ticket IGNITE-11129. But I found an > additional > > > >> place > > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at > > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation > works as > > > >> > > > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > > >> > > > > >> > But we don't have a guarantee that dataSize is multiple of > BLOCK_SZ. > > > >> > Should we use this code: > > > >> > > > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; > > > >> > > > > >> > If yes, I'll fix it. > > > >> > > > > >> > > > > > > > >
[jira] [Created] (IGNITE-11164) NPE in GridReduceQueryExecutor if topology doesn't have nodes with required partitions
Dmitry Lazurkin created IGNITE-11164:
Summary: NPE in GridReduceQueryExecutor if topology doesn't have
nodes with required partitions
Key: IGNITE-11164
URL: https://issues.apache.org/jira/browse/IGNITE-11164
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Dmitry Lazurkin
{noformat}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:590)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1803)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at java.lang.Iterable.spliterator(Iterable.java:101)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
Evgenii Zhuravlev created IGNITE-11165: -- Summary: Add note to the documentation that cache name will be used as folder name in case of using persistence Key: IGNITE-11165 URL: https://issues.apache.org/jira/browse/IGNITE-11165 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov We should add a note that it's not recommended to use symbols which are not allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Broken layout of Ignite javadoc on web
Sure, I don't see any issues with using the default style. It is
definitely better than broken CSS.
Thank you for accurate & detailed research.
If nobody minds I could apply a patch with a switch to defaults.
чт, 31 янв. 2019 г. в 11:11, Павлухин Иван :
> Hi,
>
> Continuation of the story. I build javadocs locally and checked how it
> renders with manually added images. Unfortunately there are several
> visible artifacts. I guess the reason here is that stylesheet and
> images was suitable for an older version of javadoc maven plugin but
> not for a newer one.
>
> Also I noticed that style used by Ignite is similar to Java 7 docs
> [1]. Different style is used since Java 8 [2]. And it looks like by
> default maven javadoc plugin today builds similar pages. You can see
> an example of Ignite javadoc built with default style [3].
>
> So, perhaps we can use a default style for our documentation, cannot we?
>
> [1] https://docs.oracle.com/javase/7/docs/api/java/util/BitSet.html
> [2]
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/BitSet.html
> [3] https://gist.github.com/pavlukhin/c627b31c09e4f1ae7bd04f11bafed040
>
> пн, 24 дек. 2018 г. в 17:34, Павлухин Иван :
> >
> > Hi,
> >
> > Mentioned javadoc.css references to some image resources. They present
> > for 2.3.0 release [1]. But similar url returns 404 for 2.7.0 [2]. Who
> > knows how to upload resources?
> >
> > [1] https://ignite.apache.org/releases/2.3.0/javadoc/resources
> > [2] https://ignite.apache.org/releases/2.7.0/javadoc/resources
> >
> > пн, 17 дек. 2018 г. в 16:38, Павлухин Иван :
> >
> > >
> > > Dmitriy,
> > >
> > > Yep, it looks like the problem is inside assembly/docfiles/javadoc.css
> > >
> > > I will try to dig into some time later on a spare time. Of course, if
> > > nobody fixes the problem earlier.
> > > пн, 17 дек. 2018 г. в 15:18, Dmitriy Pavlov :
> > > >
> > > > I see the same, browsers checked: Edge & Chrome. I guess it is not a
> layout
> > > > is broken, but a style missing.
> > > >
> > > > Unfortunately, I don't know how to fix. Probably we should start
> research
> > > > from ignite/pom.xml:191
> > > >
> > > >
> ${basedir}/assembly/docfiles/javadoc.css
> > > >
> > > >
> > > > пн, 17 дек. 2018 г. в 14:32, Павлухин Иван :
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that Ignite javadoc layout on web for latest versions has
> > > > > some problems. For example, I see no links near the "Class" at
> heading
> > > > > of the page [1]. Here is a screenshot [2]. Do you see the same?
> > > > >
> > > > > I was able to build javadoc on my machine. With current
> configuration
> > > > > I see the same broken layout. After using commenting out customized
> > > > > style sheet configuration (referring to
> assembly/docfiles/javadoc.css)
> > > > > I was able to obtain an html which renders fine for me.
> > > > >
> > > > > Can anyone suggest a simple solution for this?
> > > > >
> > > > > [1]
> > > > >
> https://ignite.apache.org/releases/2.7.0/javadoc/org/apache/ignite/cache/eviction/EvictionPolicy.html
> > > > > [2]
> > > > >
> https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1b257ad73f81cb4698f6105a9d1646295ba55795/javadoc_layout.png
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: Addressing usability issues with JDK 9-11
Alright, That's what needs to be done: 1. Fix sh/bat scripts work - fails on my Mac OS Mojave and latest Oracle JDK - java version "11.0.2" 2019-01-15 LTS 2. Change command line startup to output warning to stdout and logs to add necessary params to JVM 3. Make sure that examples can be compiled and run with Java 11 4. Make Ignite buildable with Java 11 Points 1-3 are quick. Dmitriy are you the one who is looking into it? When can we release Ignite 2.8. We should do this as soon as possible. - Denis On Wed, Jan 30, 2019 at 12:04 PM Dmitriy Pavlov wrote: > The only way to run examples without annoying parameters setup is to use > IntelliJ Idea templates. I guess other IDEs have a similar feature. > > I've described it here > > https://github.com/apache/ignite/tree/ignite-11140/examples#running-examples-on-jdk-91011 > > > If anyone knows how to declare such defaults using maven on IntelliJ > settings, please share. > > ср, 30 янв. 2019 г. в 14:56, Dmitriy Pavlov : > > > I've checked examples from our nightly build from TC. Pom itself was > > detected normally, I use IntelliJ Idea Ultimate Edition 2018.2. > > > > But it can't compile both for Java 8 and for Java 11. > > > > I created https://issues.apache.org/jira/browse/IGNITE-11140 so I will > > come back with fix proposals later. > > > > вт, 29 янв. 2019 г. в 18:04, Dmitriy Pavlov : > > > >> Hi Denis, > >> > >> I'm not sure that pom detection is related to Java version or to Ignite. > >> I will check examples. > >> > >> I've checked Apache Ignite TC Bot can be successfully launched using > >> instructions in > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >> using OpenJDK 10.0.2 on Windows 10. The only issue was with JAXB > >> dependencies, but it is definitely not related to Apache Ignite. > >> > >> BTW, thank you for the banner. > >> > >> Sincerely, > >> Dmitriy Pavlov > >> > >> пн, 28 янв. 2019 г. в 23:30, Denis Magda : > >> > >>> Igniters, > >>> > >>> I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > sad: > >>> > >>>- Starting a node from cmd (ignite.sh) - FAILED > >>>- Opening Ignite examples - BAD EXPERIENCE > >>> - pom.xml wasn't detected automatically, had to select it > manually > >>> - was hard to start the code samples (same issue as with cmd). > As a > >>> committer, I know how to fix it ( > >>> > >>> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >>> ), > >>> but most of the developers have no glue and will give up > >>> - The step above have to be repeated for every single sample > >>> > >>> We briefly discussed this with some community managers and our fellows > >>> will > >>> share the fix plan here. > >>> > >>> In the meantime > >>> > >>>- Artem agreed to help on the docs side: > >>>https://issues.apache.org/jira/browse/IGNITE-3 > >>>- I've added "How to Use Ignite on JDK 9, 10, 11" as a top banner of > >>>Ignite website: https://ignite.apache.org/index.html > >>> > >>> > >>> - > >>> Denis > >>> > >> >
Re: Addressing usability issues with JDK 9-11
Hi Denis, yes, I definitely will close some of these points, I hope Peter I will help with control.sh fix. Point 0. in my plan is to check TeamCity results for Java 11 Run. Unfortunately, I don't have MAC OS so I would appreciate some of MAC users may double check launch issue. Please note it may be just a warning about illegal-access, even if it is set =permit. After this warning (it is unavoidable for 1st time), everything should be ok. Sincerely, Dmitriy Pavlov чт, 31 янв. 2019 г. в 22:38, Denis Magda : > Alright, > > That's what needs to be done: > >1. Fix sh/bat scripts work - fails on my Mac OS Mojave and latest Oracle >JDK - java version "11.0.2" 2019-01-15 LTS >2. Change command line startup to output warning to stdout and logs to >add necessary params to JVM >3. Make sure that examples can be compiled and run with Java 11 >4. Make Ignite buildable with Java 11 > > Points 1-3 are quick. Dmitriy are you the one who is looking into it? When > can we release Ignite 2.8. We should do this as soon as possible. > > - > Denis > > > On Wed, Jan 30, 2019 at 12:04 PM Dmitriy Pavlov > wrote: > > > The only way to run examples without annoying parameters setup is to use > > IntelliJ Idea templates. I guess other IDEs have a similar feature. > > > > I've described it here > > > > > https://github.com/apache/ignite/tree/ignite-11140/examples#running-examples-on-jdk-91011 > > > > > > If anyone knows how to declare such defaults using maven on IntelliJ > > settings, please share. > > > > ср, 30 янв. 2019 г. в 14:56, Dmitriy Pavlov : > > > > > I've checked examples from our nightly build from TC. Pom itself was > > > detected normally, I use IntelliJ Idea Ultimate Edition 2018.2. > > > > > > But it can't compile both for Java 8 and for Java 11. > > > > > > I created https://issues.apache.org/jira/browse/IGNITE-11140 so I will > > > come back with fix proposals later. > > > > > > вт, 29 янв. 2019 г. в 18:04, Dmitriy Pavlov : > > > > > >> Hi Denis, > > >> > > >> I'm not sure that pom detection is related to Java version or to > Ignite. > > >> I will check examples. > > >> > > >> I've checked Apache Ignite TC Bot can be successfully launched using > > >> instructions in > > >> > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> using OpenJDK 10.0.2 on Windows 10. The only issue was with JAXB > > >> dependencies, but it is definitely not related to Apache Ignite. > > >> > > >> BTW, thank you for the banner. > > >> > > >> Sincerely, > > >> Dmitriy Pavlov > > >> > > >> пн, 28 янв. 2019 г. в 23:30, Denis Magda : > > >> > > >>> Igniters, > > >>> > > >>> I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > > sad: > > >>> > > >>>- Starting a node from cmd (ignite.sh) - FAILED > > >>>- Opening Ignite examples - BAD EXPERIENCE > > >>> - pom.xml wasn't detected automatically, had to select it > > manually > > >>> - was hard to start the code samples (same issue as with cmd). > > As a > > >>> committer, I know how to fix it ( > > >>> > > >>> > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >>> ), > > >>> but most of the developers have no glue and will give up > > >>> - The step above have to be repeated for every single sample > > >>> > > >>> We briefly discussed this with some community managers and our > fellows > > >>> will > > >>> share the fix plan here. > > >>> > > >>> In the meantime > > >>> > > >>>- Artem agreed to help on the docs side: > > >>>https://issues.apache.org/jira/browse/IGNITE-3 > > >>>- I've added "How to Use Ignite on JDK 9, 10, 11" as a top banner > of > > >>>Ignite website: https://ignite.apache.org/index.html > > >>> > > >>> > > >>> - > > >>> Denis > > >>> > > >> > > >
[MTCGA]: new failures in builds [2818501] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New stable failure of a flaky test in master IgniteClusterActivateDeactivateTestWithPersistence.testReActivateSimple_5_Servers_4_Clients_FromClient https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3463246719624405763&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:32:50 01-02-2019
[MTCGA]: new failures in builds [2965012] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Recently contributed test failed in master IgniteTcBotInitNewPageTest.testInitNewPagePageIdConsistency https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1440245195043386884&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - gromcase https://ci.ignite.apache.org/viewModification.html?modId=874380 - dpavlov https://ci.ignite.apache.org/viewModification.html?modId=874345 - dpavlov https://ci.ignite.apache.org/viewModification.html?modId=874392 - zaleslaw.sin https://ci.ignite.apache.org/viewModification.html?modId=874394 - maksim.stepachev https://ci.ignite.apache.org/viewModification.html?modId=874309 - kondakov87 https://ci.ignite.apache.org/viewModification.html?modId=874406 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=874401 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=874403 - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=874354 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 03:02:51 01-02-2019
[MTCGA]: new failures in builds [2818504] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New stable failure of a flaky test in master IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateCachesRestore_5_Servers_WithNewCaches https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8719815696233105132&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 08:32:51 01-02-2019
[jira] [Created] (IGNITE-11166) Web Agent: Host name verifier should be disabled in case of "-Dtrust.all=true".
Alexey Kuznetsov created IGNITE-11166: - Summary: Web Agent: Host name verifier should be disabled in case of "-Dtrust.all=true". Key: IGNITE-11166 URL: https://issues.apache.org/jira/browse/IGNITE-11166 Project: Ignite Issue Type: Bug Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov This is a regression after IGNITE-9845 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11167) Web console: web agent doesn't work properly via '3proxy' proxy server in case if autentication is ON on proxy
Pavel Konstantinov created IGNITE-11167: --- Summary: Web console: web agent doesn't work properly via '3proxy' proxy server in case if autentication is ON on proxy Key: IGNITE-11167 URL: https://issues.apache.org/jira/browse/IGNITE-11167 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov I found that web agent can't work via '3proxy' proxy server, because that server sends a 'body' part in the answer, but agent expects the only header. The agent works properly only if authentication on proxy is OFF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [MTCGA]: new failures in builds [2818501] needs to be handled
It is TC Bot complaining to quite old failure, please ignore. пт, 1 февр. 2019 г. в 01:32, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *New stable failure of a flaky test in master > IgniteClusterActivateDeactivateTestWithPersistence.testReActivateSimple_5_Servers_4_Clients_FromClient > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3463246719624405763&branch=%3Cdefault%3E&tab=testDetails > No changes in the build > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 01:32:50 01-02-2019 >
Re: [MTCGA]: new failures in builds [2965012] needs to be handled
It is my test failure, I will check and fix it as soon as possible. пт, 1 февр. 2019 г. в 03:03, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *Recently contributed test failed in master > IgniteTcBotInitNewPageTest.testInitNewPagePageIdConsistency > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1440245195043386884&branch=%3Cdefault%3E&tab=testDetails > Changes may lead to failure were done by > - gromcase > https://ci.ignite.apache.org/viewModification.html?modId=874380 > - dpavlov > https://ci.ignite.apache.org/viewModification.html?modId=874345 > - dpavlov > https://ci.ignite.apache.org/viewModification.html?modId=874392 > - zaleslaw.sin > https://ci.ignite.apache.org/viewModification.html?modId=874394 > - maksim.stepachev > https://ci.ignite.apache.org/viewModification.html?modId=874309 > - kondakov87 > https://ci.ignite.apache.org/viewModification.html?modId=874406 > - vololo100 > https://ci.ignite.apache.org/viewModification.html?modId=874401 > - vololo100 > https://ci.ignite.apache.org/viewModification.html?modId=874403 > - oignatenko > https://ci.ignite.apache.org/viewModification.html?modId=874354 > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 03:02:51 01-02-2019 >
Re: [MTCGA]: new failures in builds [2818504] needs to be handled
Please ignore, old test failure complain. It is coming only now probably because of partial rebuilding of TC bot DB after corruption. пт, 1 февр. 2019 г. в 08:33, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *New stable failure of a flaky test in master > IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateCachesRestore_5_Servers_WithNewCaches > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8719815696233105132&branch=%3Cdefault%3E&tab=testDetails > No changes in the build > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 08:32:51 01-02-2019 >
