[jira] [Created] (IGNITE-12423) PME duration histogram updates only if log info enabled
Amelchev Nikita created IGNITE-12423:
Summary: PME duration histogram updates only if log info enabled
Key: IGNITE-12423
URL: https://issues.apache.org/jira/browse/IGNITE-12423
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Fix For: 2.8
The updates histogram method is placed at the log info block:
{noformat}
if (log.isInfoEnabled()) {
...
updateDurationHistogram(System.currentTimeMillis() - initTime);
...
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
BinaryObject API confuses users
Hello, Igniters.
We have confusing API in `BinaryObjectBuilder` class.
The code below leads to the `ClassCastException`
The cause is java method resolution rules [1]
> There may be more than one such method, in which case the most specific one
> is chosen
I suggest to deprecate `setField(String name, @Nullable BinaryObjectBuilder
builder);` method and introduce
`setBinaryField(String name, @Nullable BinaryObjectBuilder builder);` instead
of it.
What do you think?
```
public class BugTest extends GridCommonAbstractTest {
@Test public void testBinaryObject() throws Exception {
try (Ignite ignite = startGrid(0)) {
BinaryObjectBuilder builder = ignite.binary().builder("testVal")
.setField("name", "John Doe", String.class);
builder.setField("name", builder.getField("name"));
}
}
}
```
[1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
Re: BinaryObject API confuses users
Nikolay,
It seems to me, that the real cause of the issue is a contract:
public T getField(String name);
Which can lead to class cast to any type. Consequently, a user gets
runtime type checks instead of compile time checks.
On the other hand, your proposal could be handy in practice, have
nothing against it.
пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
>
> Hello, Igniters.
>
> We have confusing API in `BinaryObjectBuilder` class.
>
> The code below leads to the `ClassCastException`
> The cause is java method resolution rules [1]
>
> > There may be more than one such method, in which case the most specific one
> > is chosen
>
> I suggest to deprecate `setField(String name, @Nullable BinaryObjectBuilder
> builder);` method and introduce
> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);` instead
> of it.
>
> What do you think?
>
> ```
> public class BugTest extends GridCommonAbstractTest {
> @Test public void testBinaryObject() throws Exception {
> try (Ignite ignite = startGrid(0)) {
> BinaryObjectBuilder builder = ignite.binary().builder("testVal")
> .setField("name", "John Doe", String.class);
>
> builder.setField("name", builder.getField("name"));
> }
> }
> }
> ```
>
> [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
--
Best regards,
Ivan Pavlukhin
Re: BinaryObject API confuses users
Hello!
I can see where you are getting at, can we call it "setFieldNested" instead
or something like that?
setBinaryField is confusing because we're not passing anything especially
binary, just a nested BinaryObjectBuilder.
Regards,
--
Ilya Kasnacheev
пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
> Hello, Igniters.
>
> We have confusing API in `BinaryObjectBuilder` class.
>
> The code below leads to the `ClassCastException`
> The cause is java method resolution rules [1]
>
> > There may be more than one such method, in which case the most specific
> one is chosen
>
> I suggest to deprecate `setField(String name, @Nullable
> BinaryObjectBuilder builder);` method and introduce
> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
> instead of it.
>
> What do you think?
>
> ```
> public class BugTest extends GridCommonAbstractTest {
> @Test public void testBinaryObject() throws Exception {
> try (Ignite ignite = startGrid(0)) {
> BinaryObjectBuilder builder =
> ignite.binary().builder("testVal")
> .setField("name", "John Doe", String.class);
>
> builder.setField("name", builder.getField("name"));
> }
> }
> }
> ```
>
> [1]
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
Re: BinaryObject API confuses users
Hello, Ilya.
I don’t get your point
> We don’t passing … binary, just a … BinaryObjeсtBuilder.
May be we should go with `setBinaryObjectBuilderField` or
`setBinaryObjectField`?
> 6 дек. 2019 г., в 13:38, Ilya Kasnacheev
> написал(а):
>
> Hello!
>
> I can see where you are getting at, can we call it "setFieldNested" instead
> or something like that?
>
> setBinaryField is confusing because we're not passing anything especially
> binary, just a nested BinaryObjectBuilder.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
>
>> Hello, Igniters.
>>
>> We have confusing API in `BinaryObjectBuilder` class.
>>
>> The code below leads to the `ClassCastException`
>> The cause is java method resolution rules [1]
>>
>>> There may be more than one such method, in which case the most specific
>> one is chosen
>>
>> I suggest to deprecate `setField(String name, @Nullable
>> BinaryObjectBuilder builder);` method and introduce
>> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
>> instead of it.
>>
>> What do you think?
>>
>> ```
>> public class BugTest extends GridCommonAbstractTest {
>>@Test public void testBinaryObject() throws Exception {
>>try (Ignite ignite = startGrid(0)) {
>>BinaryObjectBuilder builder =
>> ignite.binary().builder("testVal")
>>.setField("name", "John Doe", String.class);
>>
>>builder.setField("name", builder.getField("name"));
>>}
>>}
>> }
>> ```
>>
>> [1]
>> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello Maxim, I found two issues that should be included in the upcoming AI 2.8, I think. [1] https://issues.apache.org/jira/browse/IGNITE-12409 - Already done and can be cherry-picked into the release branch. [2] https://issues.apache.org/jira/browse/IGNITE-12419 - This one looks like a blocker for the release. Pull-request is available. Thanks, S. вт, 3 дек. 2019 г. в 15:30, Alexei Scherbakov : > No objections. > > вт, 3 дек. 2019 г. в 15:02, Maxim Muzafarov : > > > Alexey, > > > > > > Yet another issue [1] with corrupted B+Tree exception on the master > branch. > > My suggestion is to revert the IGNITE-11704 [3] issue from the master > > branch and rework the patch. > > > > Any objections? > > > > Configuration: > > [1] persistence = false > > [2] persistence = true > > > > class > > > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > > B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple > > [val1=1544803905, val2=844420635196573]], msg=Runtime failure on > > cursor iteration] > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5438) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5661) > > at > > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl$1.next(IgniteCacheOffheapManagerImpl.java:3020) > > at > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition$2.hasNextX(GridDhtLocalPartition.java:1226) > > at > > > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > > at > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.doClear(GridDhtLocalPartition.java:1295) > > at > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.clearTombstones(GridDhtLocalPartition.java:1242) > > at > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$ClearTombstonesTask.run0(PartitionsEvictManager.java:673) > > at > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$AbstractEvictionTask.run(PartitionsEvictManager.java:587) > > at > > > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7061) > > at > > > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > > at > > > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > at java.lang.Thread.run(Thread.java:748) > > > > Caused by: java.lang.AssertionError: Key is not ready: > > CacheDataRowAdapter [key=null, val=null, expireTime=-1, ver=null, > > cacheId=0, link=0001003c77d8] > > at > > > org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.key(CacheDataRowAdapter.java:837) > > at > > > org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:382) > > at > > > org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5200) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.findLowerBound(BPlusTree.java:5317) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer0(BPlusTree.java:5588) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.fillFromBuffer(BPlusTree.java:5376) > > at > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5428) > > > > > > [1] > > > https://ci.ignite.apache.org/viewLog.html?buildId=4807946&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache9#testNameId1910487508546147692 > > [2] > > > https://ci.ignite.apache.org/viewLog.html?buildId=4796925&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache9#testNameId7609674190425495190 > > [3] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > > > > > > On Tue, 3 Dec 2019 at 13:39, Alexei Scherbakov > > wrote: > > > > > > Maxim, > > > > > > I'm not sure this is purely a "tombstone" problem, could be a tree > > > concurrency issue. > > > Looks like the investigation is required. > > > For example, tombstone logic can be reverted but test logic is kept. > > > > > > It seems Ivan Rakov already suggested to revert a commit from master > > branch > > > in another th
Re: [TeamCIty] Issues with the disc space
aitc-lin08 was handled as well. пт, 6 дек. 2019 г. в 10:41, Maxim Muzafarov : > > Ivan, > > And another one. > Starting the build on the agent "aitc-lin08_01" > Failed to download file 'ignite.zip': No space left on device > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=4815786&buildTypeId=IgniteTests24Java8_ThinClientPython&tab=buildLog&branch_IgniteTests24Java8=%3Cdefault%3E&_focus=59 > > On Thu, 5 Dec 2019 at 16:57, Maxim Muzafarov wrote: > > > > Ivan, > > > > Starting the build on the agent "aitc-lin12_03" > > Failed to download file 'ignite.zip': No space left on device > > > > [1] > > https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4814624 > > > > On Thu, 5 Dec 2019 at 15:13, Ivan Pavlukhin wrote: > > > > > > Folks, > > > > > > Agent aitc-lin07 was cleaned. Please check that everything is working > > > fine now. If you observe other agents experiencing same problems > > > please write in this thread. > > > > > > чт, 5 дек. 2019 г. в 14:20, Anton Vinogradov : > > > > > > > > Main problem here that TC Bot ignores such failures for feature branches > > > > (since they also happen in master). > > > > So, you may gain green VISA without any checks. > > > > > > > > Everyone, > > > > Please make sure you VISAs are legal before the merge. > > > > > > > > On Thu, Dec 5, 2019 at 2:10 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > > > > > > It seems the issue is still actual. Do we have any idea what's going > > > > > on? > > > > > It's hard to work on the 2.8 release stabilization when we don't have > > > > > stable mater branch [1]. > > > > > > > > > > > > > > > [1] > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > > > > > > > > > > On Tue, 3 Dec 2019 at 20:36, Николай Ижиков > > > > > wrote: > > > > > > > > > > > > Hello, Igniters. > > > > > > > > > > > > Looks like we have an issues with the TC agents disc space [1] > > > > > > Can someone take a look? > > > > > > > > > > > > [1] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4809938&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformCPPLinuxClang > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: [TeamCIty] Issues with the disc space
listed agents seem to be broken too: aitc-lin11_02 aitc-lin10_02 aitc-lin05_01 aitc-lin04_04 On Fri, Dec 6, 2019 at 2:22 PM Ivan Pavlukhin wrote: > aitc-lin08 was handled as well. > > пт, 6 дек. 2019 г. в 10:41, Maxim Muzafarov : > > > > Ivan, > > > > And another one. > > Starting the build on the agent "aitc-lin08_01" > > Failed to download file 'ignite.zip': No space left on device > > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=4815786&buildTypeId=IgniteTests24Java8_ThinClientPython&tab=buildLog&branch_IgniteTests24Java8=%3Cdefault%3E&_focus=59 > > > > On Thu, 5 Dec 2019 at 16:57, Maxim Muzafarov wrote: > > > > > > Ivan, > > > > > > Starting the build on the agent "aitc-lin12_03" > > > Failed to download file 'ignite.zip': No space left on device > > > > > > [1] > https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4814624 > > > > > > On Thu, 5 Dec 2019 at 15:13, Ivan Pavlukhin > wrote: > > > > > > > > Folks, > > > > > > > > Agent aitc-lin07 was cleaned. Please check that everything is working > > > > fine now. If you observe other agents experiencing same problems > > > > please write in this thread. > > > > > > > > чт, 5 дек. 2019 г. в 14:20, Anton Vinogradov : > > > > > > > > > > Main problem here that TC Bot ignores such failures for feature > branches > > > > > (since they also happen in master). > > > > > So, you may gain green VISA without any checks. > > > > > > > > > > Everyone, > > > > > Please make sure you VISAs are legal before the merge. > > > > > > > > > > On Thu, Dec 5, 2019 at 2:10 PM Maxim Muzafarov > wrote: > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > It seems the issue is still actual. Do we have any idea what's > going on? > > > > > > It's hard to work on the 2.8 release stabilization when we don't > have > > > > > > stable mater branch [1]. > > > > > > > > > > > > > > > > > > [1] > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > > > > > > > > > > > > On Tue, 3 Dec 2019 at 20:36, Николай Ижиков > wrote: > > > > > > > > > > > > > > Hello, Igniters. > > > > > > > > > > > > > > Looks like we have an issues with the TC agents disc space [1] > > > > > > > Can someone take a look? > > > > > > > > > > > > > > [1] > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4809938&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformCPPLinuxClang > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin >
Re: BinaryObject API confuses users
Hello!
I think that repeating argument type name in method name is a code smell.
Rather, we should describe how this method is different from other methods
of its bunch.
In this case, it is different since it allows you to create nested binary
objects, i.e., ones with non-flat structure.
Regards,
--
Ilya Kasnacheev
пт, 6 дек. 2019 г. в 13:45, Николай Ижиков :
> Hello, Ilya.
>
> I don’t get your point
>
> > We don’t passing … binary, just a … BinaryObjeсtBuilder.
>
> May be we should go with `setBinaryObjectBuilderField` or
> `setBinaryObjectField`?
>
>
> > 6 дек. 2019 г., в 13:38, Ilya Kasnacheev
> написал(а):
> >
> > Hello!
> >
> > I can see where you are getting at, can we call it "setFieldNested"
> instead
> > or something like that?
> >
> > setBinaryField is confusing because we're not passing anything especially
> > binary, just a nested BinaryObjectBuilder.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
> >
> >> Hello, Igniters.
> >>
> >> We have confusing API in `BinaryObjectBuilder` class.
> >>
> >> The code below leads to the `ClassCastException`
> >> The cause is java method resolution rules [1]
> >>
> >>> There may be more than one such method, in which case the most specific
> >> one is chosen
> >>
> >> I suggest to deprecate `setField(String name, @Nullable
> >> BinaryObjectBuilder builder);` method and introduce
> >> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
> >> instead of it.
> >>
> >> What do you think?
> >>
> >> ```
> >> public class BugTest extends GridCommonAbstractTest {
> >>@Test public void testBinaryObject() throws Exception {
> >>try (Ignite ignite = startGrid(0)) {
> >>BinaryObjectBuilder builder =
> >> ignite.binary().builder("testVal")
> >>.setField("name", "John Doe", String.class);
> >>
> >>builder.setField("name", builder.getField("name"));
> >>}
> >>}
> >> }
> >> ```
> >>
> >> [1]
> >>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
>
>
Re: BinaryObject API confuses users
I wonder why signature is not
setField(String name, BinaryObject obj)
пт, 6 дек. 2019 г. в 15:00, Ilya Kasnacheev :
> Hello!
>
> I think that repeating argument type name in method name is a code smell.
> Rather, we should describe how this method is different from other methods
> of its bunch.
>
> In this case, it is different since it allows you to create nested binary
> objects, i.e., ones with non-flat structure.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 6 дек. 2019 г. в 13:45, Николай Ижиков :
>
> > Hello, Ilya.
> >
> > I don’t get your point
> >
> > > We don’t passing … binary, just a … BinaryObjeсtBuilder.
> >
> > May be we should go with `setBinaryObjectBuilderField` or
> > `setBinaryObjectField`?
> >
> >
> > > 6 дек. 2019 г., в 13:38, Ilya Kasnacheev
> > написал(а):
> > >
> > > Hello!
> > >
> > > I can see where you are getting at, can we call it "setFieldNested"
> > instead
> > > or something like that?
> > >
> > > setBinaryField is confusing because we're not passing anything
> especially
> > > binary, just a nested BinaryObjectBuilder.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
> > >
> > >> Hello, Igniters.
> > >>
> > >> We have confusing API in `BinaryObjectBuilder` class.
> > >>
> > >> The code below leads to the `ClassCastException`
> > >> The cause is java method resolution rules [1]
> > >>
> > >>> There may be more than one such method, in which case the most
> specific
> > >> one is chosen
> > >>
> > >> I suggest to deprecate `setField(String name, @Nullable
> > >> BinaryObjectBuilder builder);` method and introduce
> > >> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
> > >> instead of it.
> > >>
> > >> What do you think?
> > >>
> > >> ```
> > >> public class BugTest extends GridCommonAbstractTest {
> > >>@Test public void testBinaryObject() throws Exception {
> > >>try (Ignite ignite = startGrid(0)) {
> > >>BinaryObjectBuilder builder =
> > >> ignite.binary().builder("testVal")
> > >>.setField("name", "John Doe", String.class);
> > >>
> > >>builder.setField("name", builder.getField("name"));
> > >>}
> > >>}
> > >> }
> > >> ```
> > >>
> > >> [1]
> > >>
> >
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
> >
> >
>
--
Best regards,
Alexei Scherbakov
Re: BinaryObject API confuses users
I’m too, Alex.
But, this signature leads to the same error as I mentioned.
> 6 дек. 2019 г., в 15:53, Alexei Scherbakov
> написал(а):
>
> I wonder why signature is not
>
> setField(String name, BinaryObject obj)
>
> пт, 6 дек. 2019 г. в 15:00, Ilya Kasnacheev :
>
>> Hello!
>>
>> I think that repeating argument type name in method name is a code smell.
>> Rather, we should describe how this method is different from other methods
>> of its bunch.
>>
>> In this case, it is different since it allows you to create nested binary
>> objects, i.e., ones with non-flat structure.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пт, 6 дек. 2019 г. в 13:45, Николай Ижиков :
>>
>>> Hello, Ilya.
>>>
>>> I don’t get your point
>>>
We don’t passing … binary, just a … BinaryObjeсtBuilder.
>>>
>>> May be we should go with `setBinaryObjectBuilderField` or
>>> `setBinaryObjectField`?
>>>
>>>
6 дек. 2019 г., в 13:38, Ilya Kasnacheev
>>> написал(а):
Hello!
I can see where you are getting at, can we call it "setFieldNested"
>>> instead
or something like that?
setBinaryField is confusing because we're not passing anything
>> especially
binary, just a nested BinaryObjectBuilder.
Regards,
--
Ilya Kasnacheev
пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
> Hello, Igniters.
>
> We have confusing API in `BinaryObjectBuilder` class.
>
> The code below leads to the `ClassCastException`
> The cause is java method resolution rules [1]
>
>> There may be more than one such method, in which case the most
>> specific
> one is chosen
>
> I suggest to deprecate `setField(String name, @Nullable
> BinaryObjectBuilder builder);` method and introduce
> `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
> instead of it.
>
> What do you think?
>
> ```
> public class BugTest extends GridCommonAbstractTest {
> @Test public void testBinaryObject() throws Exception {
> try (Ignite ignite = startGrid(0)) {
> BinaryObjectBuilder builder =
> ignite.binary().builder("testVal")
> .setField("name", "John Doe", String.class);
>
> builder.setField("name", builder.getField("name"));
> }
> }
> }
> ```
>
> [1]
>
>>>
>> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
>>>
>>>
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
Re: BinaryObject API confuses users
Looks like it's already possible to pass binary object as value using
BinaryObjectBuilder setField(String name, Object val);
If it works we can remove a signature with BinaryObjectBuilder.
The API is truly confusing.
пт, 6 дек. 2019 г. в 15:55, Николай Ижиков :
> I’m too, Alex.
>
> But, this signature leads to the same error as I mentioned.
>
>
>
> > 6 дек. 2019 г., в 15:53, Alexei Scherbakov
> написал(а):
> >
> > I wonder why signature is not
> >
> > setField(String name, BinaryObject obj)
> >
> > пт, 6 дек. 2019 г. в 15:00, Ilya Kasnacheev :
> >
> >> Hello!
> >>
> >> I think that repeating argument type name in method name is a code
> smell.
> >> Rather, we should describe how this method is different from other
> methods
> >> of its bunch.
> >>
> >> In this case, it is different since it allows you to create nested
> binary
> >> objects, i.e., ones with non-flat structure.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> пт, 6 дек. 2019 г. в 13:45, Николай Ижиков :
> >>
> >>> Hello, Ilya.
> >>>
> >>> I don’t get your point
> >>>
> We don’t passing … binary, just a … BinaryObjeсtBuilder.
> >>>
> >>> May be we should go with `setBinaryObjectBuilderField` or
> >>> `setBinaryObjectField`?
> >>>
> >>>
> 6 дек. 2019 г., в 13:38, Ilya Kasnacheev
> >>> написал(а):
>
> Hello!
>
> I can see where you are getting at, can we call it "setFieldNested"
> >>> instead
> or something like that?
>
> setBinaryField is confusing because we're not passing anything
> >> especially
> binary, just a nested BinaryObjectBuilder.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 6 дек. 2019 г. в 13:17, Николай Ижиков :
>
> > Hello, Igniters.
> >
> > We have confusing API in `BinaryObjectBuilder` class.
> >
> > The code below leads to the `ClassCastException`
> > The cause is java method resolution rules [1]
> >
> >> There may be more than one such method, in which case the most
> >> specific
> > one is chosen
> >
> > I suggest to deprecate `setField(String name, @Nullable
> > BinaryObjectBuilder builder);` method and introduce
> > `setBinaryField(String name, @Nullable BinaryObjectBuilder builder);`
> > instead of it.
> >
> > What do you think?
> >
> > ```
> > public class BugTest extends GridCommonAbstractTest {
> > @Test public void testBinaryObject() throws Exception {
> > try (Ignite ignite = startGrid(0)) {
> > BinaryObjectBuilder builder =
> > ignite.binary().builder("testVal")
> > .setField("name", "John Doe", String.class);
> >
> > builder.setField("name", builder.getField("name"));
> > }
> > }
> > }
> > ```
> >
> > [1]
> >
> >>>
> >>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.2
> >>>
> >>>
> >>
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
>
>
--
Best regards,
Alexei Scherbakov
[MTCGA]: new failures in builds [4815611] 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 org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadWithNullKeyUsingGetAll https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8927098818965879550&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThoughUsingPutSingleEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3790886423672221427&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughUsingInvokeAll_setValue_RemoveEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2681498318389082369&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughRemove_SingleEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8793298117642492084&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadMultipleNullEntriesUsingLoadAll https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3328558920428027253&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.expiry.CacheExpiryTest.invokeGetValueWithReadThroughForNonExistentEntryShouldCallGetExpiryForCreatedEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7337820668787439799&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheLoaderTest.shouldLoadWhenCacheMissUsingGet https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6018543995721112425&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.expiry.CacheExpiryTest.loadAllWithReadThroughEnabledShouldCallGetExpiryForCreatedEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-9105662735191801339&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldNotInvokeWriteThroughCallingGetOnExistingEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7272172525770006458&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughUsingInvoke_setValue_CreateEntryGetValue https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4683130203309250975&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughReplaceExisting_SingleEntryMultipleTimes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7891852646072948353&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughUsingGetAndReplace_SingleEntryMultipleTimes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4406977921763919013&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldNotWriteThroughReplaceNonExistentKey https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3426932562911147972&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughUsingPutOfDifferentEntries https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2531906639751001464&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughUsingGetAndRemove_ExistingSingleEntry https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7108917504324815378&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master org.jsr107.tck.integration.CacheLoaderTest.shouldNotLoadUsingPutAll https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4433421382246508548&branch=%3Cdefault%3E&tab=t
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Slava, Thanks for noticing. I think we can include both of them. Do you need any help from my side? On Fri, 6 Dec 2019 at 14:02, Вячеслав Коптилин wrote: > > Hello Maxim, > > I found two issues that should be included in the upcoming AI 2.8, I think. > [1] https://issues.apache.org/jira/browse/IGNITE-12409 - Already done and > can be cherry-picked into the release branch. > [2] https://issues.apache.org/jira/browse/IGNITE-12419 - This one looks > like a blocker for the release. Pull-request is available. > > Thanks, > S. > > вт, 3 дек. 2019 г. в 15:30, Alexei Scherbakov >: > > > No objections. > > > > вт, 3 дек. 2019 г. в 15:02, Maxim Muzafarov : > > > > > Alexey, > > > > > > > > > Yet another issue [1] with corrupted B+Tree exception on the master > > branch. > > > My suggestion is to revert the IGNITE-11704 [3] issue from the master > > > branch and rework the patch. > > > > > > Any objections? > > > > > > Configuration: > > > [1] persistence = false > > > [2] persistence = true > > > > > > class > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > > > B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple > > > [val1=1544803905, val2=844420635196573]], msg=Runtime failure on > > > cursor iteration] > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5438) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5661) > > > at > > > > > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl$1.next(IgniteCacheOffheapManagerImpl.java:3020) > > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition$2.hasNextX(GridDhtLocalPartition.java:1226) > > > at > > > > > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.doClear(GridDhtLocalPartition.java:1295) > > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.clearTombstones(GridDhtLocalPartition.java:1242) > > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$ClearTombstonesTask.run0(PartitionsEvictManager.java:673) > > > at > > > > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$AbstractEvictionTask.run(PartitionsEvictManager.java:587) > > > at > > > > > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7061) > > > at > > > > > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > > > at > > > > > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > > > at > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > > at > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > > at java.lang.Thread.run(Thread.java:748) > > > > > > Caused by: java.lang.AssertionError: Key is not ready: > > > CacheDataRowAdapter [key=null, val=null, expireTime=-1, ver=null, > > > cacheId=0, link=0001003c77d8] > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.key(CacheDataRowAdapter.java:837) > > > at > > > > > org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:382) > > > at > > > > > org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5200) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.findLowerBound(BPlusTree.java:5317) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer0(BPlusTree.java:5588) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.fillFromBuffer(BPlusTree.java:5376) > > > at > > > > > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5428) > > > > > > > > > [1] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4807946&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache9#testNameId1910487508546147692 > > > [2] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4796925&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache9#testNameId7609674190425495190 > > > [3] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > > > > > > > > > > > On Tue,
Launch of the 2020 ASF Community Survey
Hello Ignite Users, Enthusiasts and Contributors, If you have an apache.org email, you should have received an email with an invitation to take the 2020 ASF Community Survey. Please take 15 minutes to complete it. If you do not have an apache.org email address or you didn’t receive a link, please follow this link to the survey: https://communitysurvey.limequery.org/454363 This survey is important because it will provide us with scientific information about our community, and shed some light on how we can collaborate better and become more diverse. Our last survey of this kind was implemented in 2016, which means that our existing data about Apache communities is outdated. The deadline to complete the survey is January 4th, 2020. You can find information about privacy on the survey’s Confluence page [1]. Your participation is paramount to the success of the Apache Ignite project! Please consider filling out the survey, and share this news with your fellow Apache contributors. As individuals form the Apache community, your opinion matters: we want to hear your voice. If you have any questions about the survey or otherwise, please reach out to us! Kindly, ASF Diversity & Inclusion https://diversity.apache.org/ [1] https://cwiki.apache.org/confluence/display/EDI/Launch+Plan+-+The+2020+ASF+Community+Survey
