[MTCGA]: new failures in builds [5897703] 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. *Test with high flaky rate in master IgniteWalRecoveryTest.testLargeRandomCrash https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6868146998171628568=%3Cdefault%3E=testDetails Changes may lead to failure were done by - maxim muzafarov https://ci.ignite.apache.org/viewModification.html?modId=918014 - vladislav pyatkov https://ci.ignite.apache.org/viewModification.html?modId=918010 - igor sapego https://ci.ignite.apache.org/viewModification.html?modId=918120 - 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 05:55:22 06-03-2021
[MTCGA]: new failures in builds [5903073] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Control Utility https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility?branch=%3Cdefault%3E 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 05:25:23 06-03-2021
[DISCUSSION] IEP-69 The evolutionary release process
Ignites, I've created the IEP-69 [1] which describes the evolutionary release process for the Apache Ignite 2.x version. You can find all the details of my suggestion there, but here you can find the crucial points: 0. Versioning - grand.major.bug-fix[-rc_number] 1. Prepare the next 3.0 release based on 2.x with some breaking compatibility changes. The same things happen from time to time with other Apache projects like Hadoop, Spark. 2. Discuss with the whole Community and assign the right release version to the activities related to the development of the new Ignite architecture (currently all the changes you can find in the ignite-3 branch). I see no 3.0 discussions on the dev-list and I see no-activity with the 3.0 version currently. So, it's better to remove the `lock` from the 3.0 version and allow the removal of obsolete features. 3. Guarantee the PDS compatibility between the `grand` versions of the Apache Ignite for the next year. 4. Guarantee the bug-fix release for the last 2.x Apache Ignite version for the next year. 5. Perform some improvements which break the backward compatibility, for instance: removing @deprecated API (except metrics), removing obsolete modules, changing the cluster defaults. You can find additional details on the IEP-69 page [1]. Please, share your thoughts. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process
[MTCGA]: new failures in builds [5897703] 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. *Test with high flaky rate in master IgniteWalRecoveryWithCompactionTest.testRandomCrash https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8929303984847909292=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testLongIndexDeletionSimple https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=376025409272028691=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testIndexDeletionTaskRemovedAfterCheckpointFinished https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3911132927333078880=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testRemoveIndexesOnTableDrop https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5809511241841564803=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testLongMulticolumnIndexDeletion https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6239131177801093464=%3Cdefault%3E=testDetails *Test with high flaky rate in master IgnitePdsCorruptedIndexTest.testCorruption https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3836675218113055947=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testLongIndexDeletionCheckWhenOneNodeStoppedAndDropIndex https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4579938704337852573=%3Cdefault%3E=testDetails *Test with high flaky rate in master LongDestroyDurableBackgroundTaskTest.testLongIndexDeletionWithRestart https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6010238287509006506=%3Cdefault%3E=testDetails Changes may lead to failure were done by - maxim muzafarov https://ci.ignite.apache.org/viewModification.html?modId=918014 - vladislav pyatkov https://ci.ignite.apache.org/viewModification.html?modId=918010 - igor sapego https://ci.ignite.apache.org/viewModification.html?modId=918120 - 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 21:55:22 05-03-2021
Re: IEP-68: Thin Client Data Streamer
Pavel,
IEP looks good to me overall. I have only one concern: currently, for thick
client "add" method we return the future which completes when the current
batch is actually added to the cache, even if "flush" method is not invoked
explicitly. For thin client with the proposed protocol we can't provide
such functionality without explicit "flush". Perhaps we should notify
client when batch actually flushed and send this notification when some
"require notification" flag is sent with the request. WDYT?
пт, 5 мар. 2021 г. в 17:03, Ivan Daschinsky :
> Agree, this is completely offtopic here.
>
> пт, 5 мар. 2021 г. в 17:02, Pavel Tupitsyn :
>
> > > custom DSL
> > This is a topic for 3.0 - would you like to start a separate thread?
> >
> > On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky
> > wrote:
> >
> > > I suppose, that the best variantl -- custom DSL similar to MongoDB
> query
> > > language.
> > > I understand that implementing this is much harder, but users want this
> > > variant.
> > >
> > > пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> > >
> > > > > I suppose this is of questional usability, same for existing
> > > > > implementation for ScanQuery and ContinousQuery
> > > >
> > > > One way or another, we need to be able to run custom logic
> > > > on the server side from thin clients.
> > > >
> > > > Our current direction can be seen as "Java is our DSL":
> > > > write server-side logic in Java, deploy to servers, call from thin
> > > clients.
> > > >
> > > > This approach is already used for Services, Compute, ScanQuery,
> > > > ContinuousQuery.
> > > >
> > > > If you have a better idea in mind, please share.
> > > >
> > > > On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky
> > > > wrote:
> > > >
> > > > > >>> - Corresponding types should exist on server nodes
> > > > > Ok, but I suppose this is of questional usability, same for
> existing
> > > > > implementation for ScanQuery and ContinousQuery.
> > > > > For queries it's probably ok to add some custom filters and put
> them
> > in
> > > > > servers' classpathes, but I can hardly imagine
> > > > > somebody wants to create custom Receiver this way.
> > > > >
> > > > > пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
> > > > >
> > > > > > > How do you suggests to serialize this object?
> > > > > >
> > > > > > Like a normal binary object. This scenario already exists for
> > > ScanQuery
> > > > > and
> > > > > > ContinuousQuery filters.
> > > > > > - It works for Java and .NET; potentially for other platforms
> > > > > > - Corresponding types should exist on server nodes
> > > > > >
> > > > > > E.g. if a Java class `MyFilter { String containsText }` is loaded
> > on
> > > > > server
> > > > > > nodes,
> > > > > > a Python thin client can easily write a corresponding
> BinaryObject
> > > with
> > > > > one
> > > > > > field to achieve server-side filtering.
> > > > > >
> > > > > >
> > > > > > > I also suppose, that closing should be done wia
> OP_RESOURCE_CLOSE
> > > > > >
> > > > > > Thanks, forgot to mention this - updated the IEP.
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky <
> > ivanda...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I also suppose, that closing should be done wia
> > OP_RESOURCE_CLOSE.
> > > > > It'is
> > > > > > > more consistent and resembles with existing cursor api.
> > > > > > >
> > > > > > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky <
> ivanda...@gmail.com
> > >:
> > > > > > >
> > > > > > > > >> Both proposed requests have a Flush flag - please see
> > Details
> > > > > > sections
> > > > > > > > in the IEP.
> > > > > > > > Ok, sorry, I missed this.
> > > > > > > > >> StreamReceiver is public API [1]
> > > > > > > > I know it. But this "object" should contains custom logic for
> > > > putting
> > > > > > > data
> > > > > > > > in cache. How do you suggests to serialize this object?
> > > > > > > > Implement custom classloader for java? What about other
> > > platforms?
> > > > > > > >
> > > > > > > > I suppose that we should not add this field, because it is
> > > > confusing.
> > > > > > > > Everything will work for local unit tests and only for java.
> > > > > > > > But in real environment this will not work at all.
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > > > > >
> > > > > > > >> Ivan,
> > > > > > > >>
> > > > > > > >> > Receiver is mostly internal stuff
> > > > > > > >> StreamReceiver is public API [1]
> > > > > > > >>
> > > > > > > >> > STREAMER_FLUSH_REQUEST should be added too
> > > > > > > >> Both proposed requests have a Flush flag - please see
> Details
> > > > > sections
> > > > > > > in
> > > > > > > >> the IEP.
> > > > > > > >> When user code calls client-side Flush method, we send the
> > > current
> > > > > > > >> client-side batch with that flag enabled,
> > > > > > > >> and flush server-side batches too.
> > > > > > > >>
> > > > > > > >> A separate request for that
Re: IEP-68: Thin Client Data Streamer
Agree, this is completely offtopic here.
пт, 5 мар. 2021 г. в 17:02, Pavel Tupitsyn :
> > custom DSL
> This is a topic for 3.0 - would you like to start a separate thread?
>
> On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky
> wrote:
>
> > I suppose, that the best variantl -- custom DSL similar to MongoDB query
> > language.
> > I understand that implementing this is much harder, but users want this
> > variant.
> >
> > пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> >
> > > > I suppose this is of questional usability, same for existing
> > > > implementation for ScanQuery and ContinousQuery
> > >
> > > One way or another, we need to be able to run custom logic
> > > on the server side from thin clients.
> > >
> > > Our current direction can be seen as "Java is our DSL":
> > > write server-side logic in Java, deploy to servers, call from thin
> > clients.
> > >
> > > This approach is already used for Services, Compute, ScanQuery,
> > > ContinuousQuery.
> > >
> > > If you have a better idea in mind, please share.
> > >
> > > On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky
> > > wrote:
> > >
> > > > >>> - Corresponding types should exist on server nodes
> > > > Ok, but I suppose this is of questional usability, same for existing
> > > > implementation for ScanQuery and ContinousQuery.
> > > > For queries it's probably ok to add some custom filters and put them
> in
> > > > servers' classpathes, but I can hardly imagine
> > > > somebody wants to create custom Receiver this way.
> > > >
> > > > пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
> > > >
> > > > > > How do you suggests to serialize this object?
> > > > >
> > > > > Like a normal binary object. This scenario already exists for
> > ScanQuery
> > > > and
> > > > > ContinuousQuery filters.
> > > > > - It works for Java and .NET; potentially for other platforms
> > > > > - Corresponding types should exist on server nodes
> > > > >
> > > > > E.g. if a Java class `MyFilter { String containsText }` is loaded
> on
> > > > server
> > > > > nodes,
> > > > > a Python thin client can easily write a corresponding BinaryObject
> > with
> > > > one
> > > > > field to achieve server-side filtering.
> > > > >
> > > > >
> > > > > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
> > > > >
> > > > > Thanks, forgot to mention this - updated the IEP.
> > > > >
> > > > >
> > > > > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky <
> ivanda...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I also suppose, that closing should be done wia
> OP_RESOURCE_CLOSE.
> > > > It'is
> > > > > > more consistent and resembles with existing cursor api.
> > > > > >
> > > > > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky >:
> > > > > >
> > > > > > > >> Both proposed requests have a Flush flag - please see
> Details
> > > > > sections
> > > > > > > in the IEP.
> > > > > > > Ok, sorry, I missed this.
> > > > > > > >> StreamReceiver is public API [1]
> > > > > > > I know it. But this "object" should contains custom logic for
> > > putting
> > > > > > data
> > > > > > > in cache. How do you suggests to serialize this object?
> > > > > > > Implement custom classloader for java? What about other
> > platforms?
> > > > > > >
> > > > > > > I suppose that we should not add this field, because it is
> > > confusing.
> > > > > > > Everything will work for local unit tests and only for java.
> > > > > > > But in real environment this will not work at all.
> > > > > > >
> > > > > > >
> > > > > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > > > >
> > > > > > >> Ivan,
> > > > > > >>
> > > > > > >> > Receiver is mostly internal stuff
> > > > > > >> StreamReceiver is public API [1]
> > > > > > >>
> > > > > > >> > STREAMER_FLUSH_REQUEST should be added too
> > > > > > >> Both proposed requests have a Flush flag - please see Details
> > > > sections
> > > > > > in
> > > > > > >> the IEP.
> > > > > > >> When user code calls client-side Flush method, we send the
> > current
> > > > > > >> client-side batch with that flag enabled,
> > > > > > >> and flush server-side batches too.
> > > > > > >>
> > > > > > >> A separate request for that does not seem to be necessary, or
> > am I
> > > > > > missing
> > > > > > >> some different use case?
> > > > > > >>
> > > > > > >> [1]
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> > > > > > >>
> > > > > > >>
> > > > > > >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky <
> > > ivanda...@gmail.com
> > > > >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too.
> Client
> > > can
> > > > > > flush
> > > > > > >> > large batches instead of closing resource.
> > > > > > >> > IMHO this is preferable than creating streamer per batch.
> > > > > > >> >
> > > > > > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky <
> > > ivanda...@gmail.com
> > > > >:
Re: IEP-68: Thin Client Data Streamer
> custom DSL
This is a topic for 3.0 - would you like to start a separate thread?
On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky wrote:
> I suppose, that the best variantl -- custom DSL similar to MongoDB query
> language.
> I understand that implementing this is much harder, but users want this
> variant.
>
> пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
>
> > > I suppose this is of questional usability, same for existing
> > > implementation for ScanQuery and ContinousQuery
> >
> > One way or another, we need to be able to run custom logic
> > on the server side from thin clients.
> >
> > Our current direction can be seen as "Java is our DSL":
> > write server-side logic in Java, deploy to servers, call from thin
> clients.
> >
> > This approach is already used for Services, Compute, ScanQuery,
> > ContinuousQuery.
> >
> > If you have a better idea in mind, please share.
> >
> > On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky
> > wrote:
> >
> > > >>> - Corresponding types should exist on server nodes
> > > Ok, but I suppose this is of questional usability, same for existing
> > > implementation for ScanQuery and ContinousQuery.
> > > For queries it's probably ok to add some custom filters and put them in
> > > servers' classpathes, but I can hardly imagine
> > > somebody wants to create custom Receiver this way.
> > >
> > > пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
> > >
> > > > > How do you suggests to serialize this object?
> > > >
> > > > Like a normal binary object. This scenario already exists for
> ScanQuery
> > > and
> > > > ContinuousQuery filters.
> > > > - It works for Java and .NET; potentially for other platforms
> > > > - Corresponding types should exist on server nodes
> > > >
> > > > E.g. if a Java class `MyFilter { String containsText }` is loaded on
> > > server
> > > > nodes,
> > > > a Python thin client can easily write a corresponding BinaryObject
> with
> > > one
> > > > field to achieve server-side filtering.
> > > >
> > > >
> > > > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
> > > >
> > > > Thanks, forgot to mention this - updated the IEP.
> > > >
> > > >
> > > > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky
> > > > wrote:
> > > >
> > > > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE.
> > > It'is
> > > > > more consistent and resembles with existing cursor api.
> > > > >
> > > > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> > > > >
> > > > > > >> Both proposed requests have a Flush flag - please see Details
> > > > sections
> > > > > > in the IEP.
> > > > > > Ok, sorry, I missed this.
> > > > > > >> StreamReceiver is public API [1]
> > > > > > I know it. But this "object" should contains custom logic for
> > putting
> > > > > data
> > > > > > in cache. How do you suggests to serialize this object?
> > > > > > Implement custom classloader for java? What about other
> platforms?
> > > > > >
> > > > > > I suppose that we should not add this field, because it is
> > confusing.
> > > > > > Everything will work for local unit tests and only for java.
> > > > > > But in real environment this will not work at all.
> > > > > >
> > > > > >
> > > > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn >:
> > > > > >
> > > > > >> Ivan,
> > > > > >>
> > > > > >> > Receiver is mostly internal stuff
> > > > > >> StreamReceiver is public API [1]
> > > > > >>
> > > > > >> > STREAMER_FLUSH_REQUEST should be added too
> > > > > >> Both proposed requests have a Flush flag - please see Details
> > > sections
> > > > > in
> > > > > >> the IEP.
> > > > > >> When user code calls client-side Flush method, we send the
> current
> > > > > >> client-side batch with that flag enabled,
> > > > > >> and flush server-side batches too.
> > > > > >>
> > > > > >> A separate request for that does not seem to be necessary, or
> am I
> > > > > missing
> > > > > >> some different use case?
> > > > > >>
> > > > > >> [1]
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client
> > can
> > > > > flush
> > > > > >> > large batches instead of closing resource.
> > > > > >> > IMHO this is preferable than creating streamer per batch.
> > > > > >> >
> > > > > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >:
> > > > > >> >
> > > > > >> > > Pavel, thank you for your effort.
> > > > > >> > >
> > > > > >> > > BTW, are you sure that receiver should be a param of
> > > > > >> > > STREAMER_START_REQUEST?
> > > > > >> > > Receiver is mostly internal stuff and I can hardly imagine
> why
> > > > > >> > > someone would decide to change defaults.
> > > > > >> > >
> > > > > >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn <
> > >
Re: IEP-68: Thin Client Data Streamer
I suppose, that the best variantl -- custom DSL similar to MongoDB query
language.
I understand that implementing this is much harder, but users want this
variant.
пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> > I suppose this is of questional usability, same for existing
> > implementation for ScanQuery and ContinousQuery
>
> One way or another, we need to be able to run custom logic
> on the server side from thin clients.
>
> Our current direction can be seen as "Java is our DSL":
> write server-side logic in Java, deploy to servers, call from thin clients.
>
> This approach is already used for Services, Compute, ScanQuery,
> ContinuousQuery.
>
> If you have a better idea in mind, please share.
>
> On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky
> wrote:
>
> > >>> - Corresponding types should exist on server nodes
> > Ok, but I suppose this is of questional usability, same for existing
> > implementation for ScanQuery and ContinousQuery.
> > For queries it's probably ok to add some custom filters and put them in
> > servers' classpathes, but I can hardly imagine
> > somebody wants to create custom Receiver this way.
> >
> > пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
> >
> > > > How do you suggests to serialize this object?
> > >
> > > Like a normal binary object. This scenario already exists for ScanQuery
> > and
> > > ContinuousQuery filters.
> > > - It works for Java and .NET; potentially for other platforms
> > > - Corresponding types should exist on server nodes
> > >
> > > E.g. if a Java class `MyFilter { String containsText }` is loaded on
> > server
> > > nodes,
> > > a Python thin client can easily write a corresponding BinaryObject with
> > one
> > > field to achieve server-side filtering.
> > >
> > >
> > > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
> > >
> > > Thanks, forgot to mention this - updated the IEP.
> > >
> > >
> > > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky
> > > wrote:
> > >
> > > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE.
> > It'is
> > > > more consistent and resembles with existing cursor api.
> > > >
> > > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> > > >
> > > > > >> Both proposed requests have a Flush flag - please see Details
> > > sections
> > > > > in the IEP.
> > > > > Ok, sorry, I missed this.
> > > > > >> StreamReceiver is public API [1]
> > > > > I know it. But this "object" should contains custom logic for
> putting
> > > > data
> > > > > in cache. How do you suggests to serialize this object?
> > > > > Implement custom classloader for java? What about other platforms?
> > > > >
> > > > > I suppose that we should not add this field, because it is
> confusing.
> > > > > Everything will work for local unit tests and only for java.
> > > > > But in real environment this will not work at all.
> > > > >
> > > > >
> > > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn :
> > > > >
> > > > >> Ivan,
> > > > >>
> > > > >> > Receiver is mostly internal stuff
> > > > >> StreamReceiver is public API [1]
> > > > >>
> > > > >> > STREAMER_FLUSH_REQUEST should be added too
> > > > >> Both proposed requests have a Flush flag - please see Details
> > sections
> > > > in
> > > > >> the IEP.
> > > > >> When user code calls client-side Flush method, we send the current
> > > > >> client-side batch with that flag enabled,
> > > > >> and flush server-side batches too.
> > > > >>
> > > > >> A separate request for that does not seem to be necessary, or am I
> > > > missing
> > > > >> some different use case?
> > > > >>
> > > > >> [1]
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> > > > >>
> > > > >>
> > > > >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky <
> ivanda...@gmail.com
> > >
> > > > >> wrote:
> > > > >>
> > > > >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client
> can
> > > > flush
> > > > >> > large batches instead of closing resource.
> > > > >> > IMHO this is preferable than creating streamer per batch.
> > > > >> >
> > > > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky <
> ivanda...@gmail.com
> > >:
> > > > >> >
> > > > >> > > Pavel, thank you for your effort.
> > > > >> > >
> > > > >> > > BTW, are you sure that receiver should be a param of
> > > > >> > > STREAMER_START_REQUEST?
> > > > >> > > Receiver is mostly internal stuff and I can hardly imagine why
> > > > >> > > someone would decide to change defaults.
> > > > >> > >
> > > > >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > >> > >
> > > > >> > >> Igor,
> > > > >> > >>
> > > > >> > >> As per our private conversation, I'll try to provide some
> perf
> > > > >> > >> measurements
> > > > >> > >> for those 4 variants, and more detailed descriptions too.
> > > > >> > >>
> > > > >> > >> Thanks!
> > > > >> > >>
> > > > >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego <
> > isap...@apache.org>
> > > > >> wrote:
Re: IEP-68: Thin Client Data Streamer
> I suppose this is of questional usability, same for existing
> implementation for ScanQuery and ContinousQuery
One way or another, we need to be able to run custom logic
on the server side from thin clients.
Our current direction can be seen as "Java is our DSL":
write server-side logic in Java, deploy to servers, call from thin clients.
This approach is already used for Services, Compute, ScanQuery,
ContinuousQuery.
If you have a better idea in mind, please share.
On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky wrote:
> >>> - Corresponding types should exist on server nodes
> Ok, but I suppose this is of questional usability, same for existing
> implementation for ScanQuery and ContinousQuery.
> For queries it's probably ok to add some custom filters and put them in
> servers' classpathes, but I can hardly imagine
> somebody wants to create custom Receiver this way.
>
> пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
>
> > > How do you suggests to serialize this object?
> >
> > Like a normal binary object. This scenario already exists for ScanQuery
> and
> > ContinuousQuery filters.
> > - It works for Java and .NET; potentially for other platforms
> > - Corresponding types should exist on server nodes
> >
> > E.g. if a Java class `MyFilter { String containsText }` is loaded on
> server
> > nodes,
> > a Python thin client can easily write a corresponding BinaryObject with
> one
> > field to achieve server-side filtering.
> >
> >
> > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
> >
> > Thanks, forgot to mention this - updated the IEP.
> >
> >
> > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky
> > wrote:
> >
> > > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE.
> It'is
> > > more consistent and resembles with existing cursor api.
> > >
> > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> > >
> > > > >> Both proposed requests have a Flush flag - please see Details
> > sections
> > > > in the IEP.
> > > > Ok, sorry, I missed this.
> > > > >> StreamReceiver is public API [1]
> > > > I know it. But this "object" should contains custom logic for putting
> > > data
> > > > in cache. How do you suggests to serialize this object?
> > > > Implement custom classloader for java? What about other platforms?
> > > >
> > > > I suppose that we should not add this field, because it is confusing.
> > > > Everything will work for local unit tests and only for java.
> > > > But in real environment this will not work at all.
> > > >
> > > >
> > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn :
> > > >
> > > >> Ivan,
> > > >>
> > > >> > Receiver is mostly internal stuff
> > > >> StreamReceiver is public API [1]
> > > >>
> > > >> > STREAMER_FLUSH_REQUEST should be added too
> > > >> Both proposed requests have a Flush flag - please see Details
> sections
> > > in
> > > >> the IEP.
> > > >> When user code calls client-side Flush method, we send the current
> > > >> client-side batch with that flag enabled,
> > > >> and flush server-side batches too.
> > > >>
> > > >> A separate request for that does not seem to be necessary, or am I
> > > missing
> > > >> some different use case?
> > > >>
> > > >> [1]
> > > >>
> > > >>
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> > > >>
> > > >>
> > > >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky >
> > > >> wrote:
> > > >>
> > > >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can
> > > flush
> > > >> > large batches instead of closing resource.
> > > >> > IMHO this is preferable than creating streamer per batch.
> > > >> >
> > > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky >:
> > > >> >
> > > >> > > Pavel, thank you for your effort.
> > > >> > >
> > > >> > > BTW, are you sure that receiver should be a param of
> > > >> > > STREAMER_START_REQUEST?
> > > >> > > Receiver is mostly internal stuff and I can hardly imagine why
> > > >> > > someone would decide to change defaults.
> > > >> > >
> > > >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > >> > >
> > > >> > >> Igor,
> > > >> > >>
> > > >> > >> As per our private conversation, I'll try to provide some perf
> > > >> > >> measurements
> > > >> > >> for those 4 variants, and more detailed descriptions too.
> > > >> > >>
> > > >> > >> Thanks!
> > > >> > >>
> > > >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego <
> isap...@apache.org>
> > > >> wrote:
> > > >> > >>
> > > >> > >> > Pavel,
> > > >> > >> >
> > > >> > >> > I've checked the IEP and I like it. The only thing that
> seems a
> > > bit
> > > >> > >> > confusing to me
> > > >> > >> > is that there are 4 different variants for clients but there
> > are
> > > >> cons
> > > >> > >> and
> > > >> > >> > pros for
> > > >> > >> > different variants. Maybe at least few sentences should be
> > > written
> > > >> > here
> > > >> > >> to
> > > >> > >> > give developers who are not familiar with DataStreamer some
> > ideas
> >
Re: Adding metrics of using WAL archive
Yes, definitely. > 5 марта 2021 г., в 16:31, ткаленко кирилл написал(а): > > Hi Nikolay, can you do a review? > > 02.03.2021, 18:59, "Nikolay Izhikov" : >> +1 For this. >> >>> 2 марта 2021 г., в 18:32, ткаленко кирилл >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> I thought about your proposal and offer the following two metrics: >>> >>> 1)The number of bytes logged to the WAL; >>> 2)The number of compressed bytes in the WAL. >>> >>> Monotonically increasing long. >>> >>> WDYT?
Re: Adding metrics of using WAL archive
Hi Nikolay, can you do a review? 02.03.2021, 18:59, "Nikolay Izhikov" : > +1 For this. > >> 2 марта 2021 г., в 18:32, ткаленко кирилл написал(а): >> >> Hi, Nikolay! >> >> I thought about your proposal and offer the following two metrics: >> >> 1)The number of bytes logged to the WAL; >> 2)The number of compressed bytes in the WAL. >> >> Monotonically increasing long. >> >> WDYT?
Re: IEP-68: Thin Client Data Streamer
>>> - Corresponding types should exist on server nodes
Ok, but I suppose this is of questional usability, same for existing
implementation for ScanQuery and ContinousQuery.
For queries it's probably ok to add some custom filters and put them in
servers' classpathes, but I can hardly imagine
somebody wants to create custom Receiver this way.
пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn :
> > How do you suggests to serialize this object?
>
> Like a normal binary object. This scenario already exists for ScanQuery and
> ContinuousQuery filters.
> - It works for Java and .NET; potentially for other platforms
> - Corresponding types should exist on server nodes
>
> E.g. if a Java class `MyFilter { String containsText }` is loaded on server
> nodes,
> a Python thin client can easily write a corresponding BinaryObject with one
> field to achieve server-side filtering.
>
>
> > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
>
> Thanks, forgot to mention this - updated the IEP.
>
>
> On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky
> wrote:
>
> > I also suppose, that closing should be done wia OP_RESOURCE_CLOSE. It'is
> > more consistent and resembles with existing cursor api.
> >
> > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> >
> > > >> Both proposed requests have a Flush flag - please see Details
> sections
> > > in the IEP.
> > > Ok, sorry, I missed this.
> > > >> StreamReceiver is public API [1]
> > > I know it. But this "object" should contains custom logic for putting
> > data
> > > in cache. How do you suggests to serialize this object?
> > > Implement custom classloader for java? What about other platforms?
> > >
> > > I suppose that we should not add this field, because it is confusing.
> > > Everything will work for local unit tests and only for java.
> > > But in real environment this will not work at all.
> > >
> > >
> > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn :
> > >
> > >> Ivan,
> > >>
> > >> > Receiver is mostly internal stuff
> > >> StreamReceiver is public API [1]
> > >>
> > >> > STREAMER_FLUSH_REQUEST should be added too
> > >> Both proposed requests have a Flush flag - please see Details sections
> > in
> > >> the IEP.
> > >> When user code calls client-side Flush method, we send the current
> > >> client-side batch with that flag enabled,
> > >> and flush server-side batches too.
> > >>
> > >> A separate request for that does not seem to be necessary, or am I
> > missing
> > >> some different use case?
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> > >>
> > >>
> > >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky
> > >> wrote:
> > >>
> > >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can
> > flush
> > >> > large batches instead of closing resource.
> > >> > IMHO this is preferable than creating streamer per batch.
> > >> >
> > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky :
> > >> >
> > >> > > Pavel, thank you for your effort.
> > >> > >
> > >> > > BTW, are you sure that receiver should be a param of
> > >> > > STREAMER_START_REQUEST?
> > >> > > Receiver is mostly internal stuff and I can hardly imagine why
> > >> > > someone would decide to change defaults.
> > >> > >
> > >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn >:
> > >> > >
> > >> > >> Igor,
> > >> > >>
> > >> > >> As per our private conversation, I'll try to provide some perf
> > >> > >> measurements
> > >> > >> for those 4 variants, and more detailed descriptions too.
> > >> > >>
> > >> > >> Thanks!
> > >> > >>
> > >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego
> > >> wrote:
> > >> > >>
> > >> > >> > Pavel,
> > >> > >> >
> > >> > >> > I've checked the IEP and I like it. The only thing that seems a
> > bit
> > >> > >> > confusing to me
> > >> > >> > is that there are 4 different variants for clients but there
> are
> > >> cons
> > >> > >> and
> > >> > >> > pros for
> > >> > >> > different variants. Maybe at least few sentences should be
> > written
> > >> > here
> > >> > >> to
> > >> > >> > give developers who are not familiar with DataStreamer some
> ideas
> > >> and
> > >> > >> make
> > >> > >> > it easier for them to choose.
> > >> > >> >
> > >> > >> > Best Regards,
> > >> > >> > Igor
> > >> > >> >
> > >> > >> >
> > >> > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn <
> > >> ptupit...@apache.org>
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> > > Igniters,
> > >> > >> > >
> > >> > >> > > Please review the IEP [1] and let me know what you think.
> > >> > >> > >
> > >> > >> > > [1]
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Sincerely yours, Ivan Daschinskiy
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Sincerely yours, Ivan Daschinskiy
> > >> >
> > >>
> > >
> > >
> > >
Re: IEP-68: Thin Client Data Streamer
> How do you suggests to serialize this object?
Like a normal binary object. This scenario already exists for ScanQuery and
ContinuousQuery filters.
- It works for Java and .NET; potentially for other platforms
- Corresponding types should exist on server nodes
E.g. if a Java class `MyFilter { String containsText }` is loaded on server
nodes,
a Python thin client can easily write a corresponding BinaryObject with one
field to achieve server-side filtering.
> I also suppose, that closing should be done wia OP_RESOURCE_CLOSE
Thanks, forgot to mention this - updated the IEP.
On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky wrote:
> I also suppose, that closing should be done wia OP_RESOURCE_CLOSE. It'is
> more consistent and resembles with existing cursor api.
>
> пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
>
> > >> Both proposed requests have a Flush flag - please see Details sections
> > in the IEP.
> > Ok, sorry, I missed this.
> > >> StreamReceiver is public API [1]
> > I know it. But this "object" should contains custom logic for putting
> data
> > in cache. How do you suggests to serialize this object?
> > Implement custom classloader for java? What about other platforms?
> >
> > I suppose that we should not add this field, because it is confusing.
> > Everything will work for local unit tests and only for java.
> > But in real environment this will not work at all.
> >
> >
> > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn :
> >
> >> Ivan,
> >>
> >> > Receiver is mostly internal stuff
> >> StreamReceiver is public API [1]
> >>
> >> > STREAMER_FLUSH_REQUEST should be added too
> >> Both proposed requests have a Flush flag - please see Details sections
> in
> >> the IEP.
> >> When user code calls client-side Flush method, we send the current
> >> client-side batch with that flag enabled,
> >> and flush server-side batches too.
> >>
> >> A separate request for that does not seem to be necessary, or am I
> missing
> >> some different use case?
> >>
> >> [1]
> >>
> >>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html
> >>
> >>
> >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky
> >> wrote:
> >>
> >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can
> flush
> >> > large batches instead of closing resource.
> >> > IMHO this is preferable than creating streamer per batch.
> >> >
> >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky :
> >> >
> >> > > Pavel, thank you for your effort.
> >> > >
> >> > > BTW, are you sure that receiver should be a param of
> >> > > STREAMER_START_REQUEST?
> >> > > Receiver is mostly internal stuff and I can hardly imagine why
> >> > > someone would decide to change defaults.
> >> > >
> >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn :
> >> > >
> >> > >> Igor,
> >> > >>
> >> > >> As per our private conversation, I'll try to provide some perf
> >> > >> measurements
> >> > >> for those 4 variants, and more detailed descriptions too.
> >> > >>
> >> > >> Thanks!
> >> > >>
> >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego
> >> wrote:
> >> > >>
> >> > >> > Pavel,
> >> > >> >
> >> > >> > I've checked the IEP and I like it. The only thing that seems a
> bit
> >> > >> > confusing to me
> >> > >> > is that there are 4 different variants for clients but there are
> >> cons
> >> > >> and
> >> > >> > pros for
> >> > >> > different variants. Maybe at least few sentences should be
> written
> >> > here
> >> > >> to
> >> > >> > give developers who are not familiar with DataStreamer some ideas
> >> and
> >> > >> make
> >> > >> > it easier for them to choose.
> >> > >> >
> >> > >> > Best Regards,
> >> > >> > Igor
> >> > >> >
> >> > >> >
> >> > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn <
> >> ptupit...@apache.org>
> >> > >> > wrote:
> >> > >> >
> >> > >> > > Igniters,
> >> > >> > >
> >> > >> > > Please review the IEP [1] and let me know what you think.
> >> > >> > >
> >> > >> > > [1]
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > Sincerely yours, Ivan Daschinskiy
> >> > >
> >> >
> >> >
> >> > --
> >> > Sincerely yours, Ivan Daschinskiy
> >> >
> >>
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
Re: IEP-68: Thin Client Data Streamer
I also suppose, that closing should be done wia OP_RESOURCE_CLOSE. It'is more consistent and resembles with existing cursor api. пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky : > >> Both proposed requests have a Flush flag - please see Details sections > in the IEP. > Ok, sorry, I missed this. > >> StreamReceiver is public API [1] > I know it. But this "object" should contains custom logic for putting data > in cache. How do you suggests to serialize this object? > Implement custom classloader for java? What about other platforms? > > I suppose that we should not add this field, because it is confusing. > Everything will work for local unit tests and only for java. > But in real environment this will not work at all. > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn : > >> Ivan, >> >> > Receiver is mostly internal stuff >> StreamReceiver is public API [1] >> >> > STREAMER_FLUSH_REQUEST should be added too >> Both proposed requests have a Flush flag - please see Details sections in >> the IEP. >> When user code calls client-side Flush method, we send the current >> client-side batch with that flag enabled, >> and flush server-side batches too. >> >> A separate request for that does not seem to be necessary, or am I missing >> some different use case? >> >> [1] >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html >> >> >> On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky >> wrote: >> >> > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush >> > large batches instead of closing resource. >> > IMHO this is preferable than creating streamer per batch. >> > >> > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky : >> > >> > > Pavel, thank you for your effort. >> > > >> > > BTW, are you sure that receiver should be a param of >> > > STREAMER_START_REQUEST? >> > > Receiver is mostly internal stuff and I can hardly imagine why >> > > someone would decide to change defaults. >> > > >> > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn : >> > > >> > >> Igor, >> > >> >> > >> As per our private conversation, I'll try to provide some perf >> > >> measurements >> > >> for those 4 variants, and more detailed descriptions too. >> > >> >> > >> Thanks! >> > >> >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego >> wrote: >> > >> >> > >> > Pavel, >> > >> > >> > >> > I've checked the IEP and I like it. The only thing that seems a bit >> > >> > confusing to me >> > >> > is that there are 4 different variants for clients but there are >> cons >> > >> and >> > >> > pros for >> > >> > different variants. Maybe at least few sentences should be written >> > here >> > >> to >> > >> > give developers who are not familiar with DataStreamer some ideas >> and >> > >> make >> > >> > it easier for them to choose. >> > >> > >> > >> > Best Regards, >> > >> > Igor >> > >> > >> > >> > >> > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn < >> ptupit...@apache.org> >> > >> > wrote: >> > >> > >> > >> > > Igniters, >> > >> > > >> > >> > > Please review the IEP [1] and let me know what you think. >> > >> > > >> > >> > > [1] >> > >> > > >> > >> > > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer >> > >> > > >> > >> > >> > >> >> > > >> > > >> > > -- >> > > Sincerely yours, Ivan Daschinskiy >> > > >> > >> > >> > -- >> > Sincerely yours, Ivan Daschinskiy >> > >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Sincerely yours, Ivan Daschinskiy
Re: IEP-68: Thin Client Data Streamer
>> Both proposed requests have a Flush flag - please see Details sections in the IEP. Ok, sorry, I missed this. >> StreamReceiver is public API [1] I know it. But this "object" should contains custom logic for putting data in cache. How do you suggests to serialize this object? Implement custom classloader for java? What about other platforms? I suppose that we should not add this field, because it is confusing. Everything will work for local unit tests and only for java. But in real environment this will not work at all. пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn : > Ivan, > > > Receiver is mostly internal stuff > StreamReceiver is public API [1] > > > STREAMER_FLUSH_REQUEST should be added too > Both proposed requests have a Flush flag - please see Details sections in > the IEP. > When user code calls client-side Flush method, we send the current > client-side batch with that flag enabled, > and flush server-side batches too. > > A separate request for that does not seem to be necessary, or am I missing > some different use case? > > [1] > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html > > > On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky > wrote: > > > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush > > large batches instead of closing resource. > > IMHO this is preferable than creating streamer per batch. > > > > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky : > > > > > Pavel, thank you for your effort. > > > > > > BTW, are you sure that receiver should be a param of > > > STREAMER_START_REQUEST? > > > Receiver is mostly internal stuff and I can hardly imagine why > > > someone would decide to change defaults. > > > > > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn : > > > > > >> Igor, > > >> > > >> As per our private conversation, I'll try to provide some perf > > >> measurements > > >> for those 4 variants, and more detailed descriptions too. > > >> > > >> Thanks! > > >> > > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego > wrote: > > >> > > >> > Pavel, > > >> > > > >> > I've checked the IEP and I like it. The only thing that seems a bit > > >> > confusing to me > > >> > is that there are 4 different variants for clients but there are > cons > > >> and > > >> > pros for > > >> > different variants. Maybe at least few sentences should be written > > here > > >> to > > >> > give developers who are not familiar with DataStreamer some ideas > and > > >> make > > >> > it easier for them to choose. > > >> > > > >> > Best Regards, > > >> > Igor > > >> > > > >> > > > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn > > > >> > wrote: > > >> > > > >> > > Igniters, > > >> > > > > >> > > Please review the IEP [1] and let me know what you think. > > >> > > > > >> > > [1] > > >> > > > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer > > >> > > > > >> > > > >> > > > > > > > > > -- > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > -- Sincerely yours, Ivan Daschinskiy
Re: IEP-68: Thin Client Data Streamer
Ivan, > Receiver is mostly internal stuff StreamReceiver is public API [1] > STREAMER_FLUSH_REQUEST should be added too Both proposed requests have a Flush flag - please see Details sections in the IEP. When user code calls client-side Flush method, we send the current client-side batch with that flag enabled, and flush server-side batches too. A separate request for that does not seem to be necessary, or am I missing some different use case? [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/stream/package-summary.html On Fri, Mar 5, 2021 at 2:50 PM Ivan Daschinsky wrote: > IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush > large batches instead of closing resource. > IMHO this is preferable than creating streamer per batch. > > пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky : > > > Pavel, thank you for your effort. > > > > BTW, are you sure that receiver should be a param of > > STREAMER_START_REQUEST? > > Receiver is mostly internal stuff and I can hardly imagine why > > someone would decide to change defaults. > > > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn : > > > >> Igor, > >> > >> As per our private conversation, I'll try to provide some perf > >> measurements > >> for those 4 variants, and more detailed descriptions too. > >> > >> Thanks! > >> > >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote: > >> > >> > Pavel, > >> > > >> > I've checked the IEP and I like it. The only thing that seems a bit > >> > confusing to me > >> > is that there are 4 different variants for clients but there are cons > >> and > >> > pros for > >> > different variants. Maybe at least few sentences should be written > here > >> to > >> > give developers who are not familiar with DataStreamer some ideas and > >> make > >> > it easier for them to choose. > >> > > >> > Best Regards, > >> > Igor > >> > > >> > > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn > >> > wrote: > >> > > >> > > Igniters, > >> > > > >> > > Please review the IEP [1] and let me know what you think. > >> > > > >> > > [1] > >> > > > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer > >> > > > >> > > >> > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > > > -- > Sincerely yours, Ivan Daschinskiy >
Re: Minor PR
Hello! Please run tests against this change, get a green TC visa for the ticket. Regards, -- Ilya Kasnacheev ср, 3 мар. 2021 г. в 17:13, Atri Sharma : > Hi, > > Please help review this PR: > > https://github.com/apache/ignite/pull/8845 > > Regards, > > Atri >
Re: IEP-68: Thin Client Data Streamer
IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush large batches instead of closing resource. IMHO this is preferable than creating streamer per batch. пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky : > Pavel, thank you for your effort. > > BTW, are you sure that receiver should be a param of > STREAMER_START_REQUEST? > Receiver is mostly internal stuff and I can hardly imagine why > someone would decide to change defaults. > > пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn : > >> Igor, >> >> As per our private conversation, I'll try to provide some perf >> measurements >> for those 4 variants, and more detailed descriptions too. >> >> Thanks! >> >> On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote: >> >> > Pavel, >> > >> > I've checked the IEP and I like it. The only thing that seems a bit >> > confusing to me >> > is that there are 4 different variants for clients but there are cons >> and >> > pros for >> > different variants. Maybe at least few sentences should be written here >> to >> > give developers who are not familiar with DataStreamer some ideas and >> make >> > it easier for them to choose. >> > >> > Best Regards, >> > Igor >> > >> > >> > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn >> > wrote: >> > >> > > Igniters, >> > > >> > > Please review the IEP [1] and let me know what you think. >> > > >> > > [1] >> > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer >> > > >> > >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Sincerely yours, Ivan Daschinskiy
Re: IEP-68: Thin Client Data Streamer
Pavel, thank you for your effort. BTW, are you sure that receiver should be a param of STREAMER_START_REQUEST? Receiver is mostly internal stuff and I can hardly imagine why someone would decide to change defaults. пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn : > Igor, > > As per our private conversation, I'll try to provide some perf measurements > for those 4 variants, and more detailed descriptions too. > > Thanks! > > On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote: > > > Pavel, > > > > I've checked the IEP and I like it. The only thing that seems a bit > > confusing to me > > is that there are 4 different variants for clients but there are cons and > > pros for > > different variants. Maybe at least few sentences should be written here > to > > give developers who are not familiar with DataStreamer some ideas and > make > > it easier for them to choose. > > > > Best Regards, > > Igor > > > > > > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn > > wrote: > > > > > Igniters, > > > > > > Please review the IEP [1] and let me know what you think. > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer > > > > > > -- Sincerely yours, Ivan Daschinskiy
Re: [VOTE] Release Apache Ignite 2.10.0 RC1
+1 (binding)
Checked C++ compilation, C++ examples
Best Regards,
Igor
On Fri, Mar 5, 2021 at 12:32 AM Denis Magda wrote:
> +1 (binding)
>
> Downloaded the binary package and started a 2-node cluster on MacOS with
> ignite.sh.
>
> -
> Denis
>
>
> On Wed, Mar 3, 2021 at 1:03 PM Maxim Muzafarov wrote:
>
> > Dear Community,
> >
> > The release candidate is ready. The rest of the documentation pages
> > will be completed prior to the release announcement message. Please,
> > see the links below.
> >
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist/dev/ignite/2.10.0-rc1/
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.10.0-rc1/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1506
> >
> >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> >
> > Tag name is 2.10.0-rc1:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.10.0-rc1
> >
> > RELEASE_NOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.10
> >
> > Complete list of resolved issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.10'))
> >
> > DEVNOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.10
> >
> >
> > Additional checks have been performed (available for users included into
> > the release group on TeamCity).
> >
> > TC [Check RC: Licenses, compile, chksum]
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901349=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> >
> > TC [3] Build & Upload Nuget Staging Packages
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901347=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> >
> > TC [2] Compare w/ Previous Release
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901351=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=artifacts_Releases_ApacheIgniteMain=ignite-2.9.1#%2Fresults
> >
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.10.0-rc1
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.10.0-rc1 (explain why)
> >
> > See notes on how to verify release here
> > https://www.apache.org/info/verification.html
> > and
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >
> > This vote will be open until Mon Mar 8, 15:00 UTC.
> > Please, write me down the thread if you need additional time to check
> > the release.
> >
> >
> https://www.timeanddate.com/countdown/vote?iso=20210308T18=166=VOTE+on+the+Apache+Ignite+Release+2.10.0+RC1=sanserif
> >
>
Re: [VOTE] Release Apache Ignite 2.10.0 RC1
Hello!
-1 (binding)
I have faced two sqlline issues in 30 seconds, of which one is mostly
cosmetic while the other is very annoying:
https://issues.apache.org/jira/browse/IGNITE-14284
https://issues.apache.org/jira/browse/IGNITE-14285
Since the new sqlline uses different history file format but same file
name, we will permanently ruin the sqlline experience for developers if we
release now. I suggest we take the time to fix both.
Also built and installed C++ sources without issues.
Installed & run deb package, started a node.
I was able to build C# platform using ./build.sh, but it was totally not
obvious which are the next steps from there.
Totally not obvious how to start node now, or how to install what was built.
I have tried running dotnet run from examples/dotnetcore but it gave me a
lot of errors.
Maybe we did not have changes in 2.10 specifically, but I remember it is
very annoying every time to remember which steps are required to run
anything with dotnetcore on linux, and docs do not help totally.
Maybe we could address that. Please point me to the docs if they indeed
exist, regarding how I could check the functioning of dotnetcore after
building it from the source.
Please see attached file for error messages.
Regards,
--
Ilya Kasnacheev
пт, 5 мар. 2021 г. в 00:32, Denis Magda :
> +1 (binding)
>
> Downloaded the binary package and started a 2-node cluster on MacOS with
> ignite.sh.
>
> -
> Denis
>
>
> On Wed, Mar 3, 2021 at 1:03 PM Maxim Muzafarov wrote:
>
> > Dear Community,
> >
> > The release candidate is ready. The rest of the documentation pages
> > will be completed prior to the release announcement message. Please,
> > see the links below.
> >
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist/dev/ignite/2.10.0-rc1/
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.10.0-rc1/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1506
> >
> >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> >
> > Tag name is 2.10.0-rc1:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.10.0-rc1
> >
> > RELEASE_NOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.10
> >
> > Complete list of resolved issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.10'))
> >
> > DEVNOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.10
> >
> >
> > Additional checks have been performed (available for users included into
> > the release group on TeamCity).
> >
> > TC [Check RC: Licenses, compile, chksum]
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901349=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> >
> > TC [3] Build & Upload Nuget Staging Packages
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901347=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> >
> > TC [2] Compare w/ Previous Release
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5901351=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=artifacts_Releases_ApacheIgniteMain=ignite-2.9.1#%2Fresults
> >
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.10.0-rc1
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.10.0-rc1 (explain why)
> >
> > See notes on how to verify release here
> > https://www.apache.org/info/verification.html
> > and
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >
> > This vote will be open until Mon Mar 8, 15:00 UTC.
> > Please, write me down the thread if you need additional time to check
> > the release.
> >
> >
> https://www.timeanddate.com/countdown/vote?iso=20210308T18=166=VOTE+on+the+Apache+Ignite+Release+2.10.0+RC1=sanserif
> >
>
~/Downloads/2.10/apache-ignite-2.10.0-src/modules/platforms/dotnet/examples/dotnetcore%
dotnet run
13:07
/usr/share/dotnet/sdk/3.1.406/Microsoft.Common.CurrentVersion.targets(2084,5):
warning MSB3245: Не удалось разрешить данную ссылку. Не удалось обнаружить
сборку "Apache.Ignite.Core". Убедитесь, что сборка существует на диске. Если
данная ссылка требуется в коде, это может вызвать ошибки компиляции.
[/home/ikasnacheev/Downloads/2.11/apache-ignite-2.10.0-src/modules/platforms/dotnet/examples/dotnetcore/Apache.Ignite.Examples.csproj]
/usr/share/dotnet/sdk/3.1.406/Microsoft.Common.CurrentVersion.targets(2084,5):
warning MSB3245: Не удалось разрешить данную ссылку. Не удалось обнаружить
сборку "Apache.Ignite.Linq". Убедитесь, что сборка существует
Re: IEP-68: Thin Client Data Streamer
Igor, As per our private conversation, I'll try to provide some perf measurements for those 4 variants, and more detailed descriptions too. Thanks! On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote: > Pavel, > > I've checked the IEP and I like it. The only thing that seems a bit > confusing to me > is that there are 4 different variants for clients but there are cons and > pros for > different variants. Maybe at least few sentences should be written here to > give developers who are not familiar with DataStreamer some ideas and make > it easier for them to choose. > > Best Regards, > Igor > > > On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn > wrote: > > > Igniters, > > > > Please review the IEP [1] and let me know what you think. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer > > >
Re: IEP-68: Thin Client Data Streamer
Pavel, I've checked the IEP and I like it. The only thing that seems a bit confusing to me is that there are 4 different variants for clients but there are cons and pros for different variants. Maybe at least few sentences should be written here to give developers who are not familiar with DataStreamer some ideas and make it easier for them to choose. Best Regards, Igor On Thu, Mar 4, 2021 at 3:14 PM Pavel Tupitsyn wrote: > Igniters, > > Please review the IEP [1] and let me know what you think. > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer >
[jira] [Created] (IGNITE-14285) sqllline: `Bad history file syntax!'
Ilya Kasnacheev created IGNITE-14285:
Summary: sqllline: `Bad history file syntax!'
Key: IGNITE-14285
URL: https://issues.apache.org/jira/browse/IGNITE-14285
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Ilya Kasnacheev
When starting the updated sqlline in 2.10, I can see the following error
message:
{code}
~/Downloads/2.10/apache-ignite-slim-2.10.0-bin% bin/sqlline.sh
мар 05, 2021 12:30:46 PM org.jline.utils.Log logr
WARNING: Failed to load history
java.lang.IllegalArgumentException: Bad history file syntax! The history file
`/home/ikasnacheev/.sqlline/history` may be an older history: please remove it
or use a different history file.
at
org.jline.reader.impl.history.DefaultHistory.addHistoryLine(DefaultHistory.java:185)
at
org.jline.reader.impl.history.DefaultHistory.addHistoryLine(DefaultHistory.java:169)
at
org.jline.reader.impl.history.DefaultHistory.lambda$load$0(DefaultHistory.java:86)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
at
org.jline.reader.impl.history.DefaultHistory.load(DefaultHistory.java:86)
at
org.jline.reader.impl.history.DefaultHistory.attach(DefaultHistory.java:69)
at sqlline.SqlLine.getConsoleReader(SqlLine.java:618)
at sqlline.SqlLine.begin(SqlLine.java:511)
at sqlline.SqlLine.start(SqlLine.java:267)
at sqlline.SqlLine.main(SqlLine.java:206)
{code}
Moreover, if I remove the file, and run some command, then the old sqlline will
use the history incorrectly:
{code}
sqlline version 1.3.0
sqlline> 1614936870022:select * from person;
{code}
This is going to be a problem for all Ignite developers who use more than one
version of Ignite on the same box, e.g. the entirely development community.
I recommend changing the default history file location to e.g.
~/.sqlline/apache-ignite.history.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14284) sqlline: `Property "url" is required'
Ilya Kasnacheev created IGNITE-14284:
Summary: sqlline: `Property "url" is required'
Key: IGNITE-14284
URL: https://issues.apache.org/jira/browse/IGNITE-14284
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Ilya Kasnacheev
Currently, when you run sqlline.sh, the following output is shown:
{code}
~/Downloads/2.10/apache-ignite-slim-2.10.0-bin% bin/sqlline.sh
Property "url" is required
sqlline version 1.9.0
sqlline>
{code}
We did not have this confusing warning when using sqlline 1.3.0. From this on,
it will work as expected, with !connect jdbc:ignite:thin://localhost, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Missed (non-suited) tests
Yeap! I'll start implementing it next week. I think I'll create new jobs and when everything is OK — will switch settings in template to new chain. It will take some time to do everything right though. > On 5 Mar 2021, at 09:28, Maksim Timonin wrote: > > Hi, Petr! > > I've created a ticket [1] for that and assigned it on you. Could you please > catch it when you have time? > > [1] https://issues.apache.org/jira/browse/IGNITE-14283 > > On Wed, Mar 3, 2021 at 11:06 PM Maxim Muzafarov wrote: > >> Max, >> >>> There is an overhead for running git + mvn test twice, but it is a cost >> for the flexibility. >> >> Yes, I mean this issue. I have no objections, the build queue seems to >> be empty most of the time. >> >> On Wed, 3 Mar 2021 at 21:01, Max Timonin wrote: >>> >>> Yes, they can be performed as parallel, as doesn't depend on each other. >>> There is an overhead for running git + mvn test twice, but it is a cost >> for >>> the flexibility. >>> >>> On Wed, Mar 3, 2021 at 8:55 PM Max Timonin >> wrote: >>> I mean that any TC job with tests depends on both [Build], [Sanity Checks]. No tests run if any of those jobs failed. [Build] prepares ignite.zip for distribution between TC agents (mvn install). [Sanity Checks] checks that code is correct in terms of our static >> checks (mvn test). Indeed it can be run as a single job, but in favor of flexibility in configuration (enable / disable checks) it is OK to separate it in 2 >> steps. Do you have some objections to do it that way? On Wed, Mar 3, 2021 at 8:45 PM Maxim Muzafarov >> wrote: > Maxim, > > Can you clarify what means '[Sanity Checks] runs in parallel with > [Build]'? AFAIK the checks need the build results to run themselves. > > On Wed, 3 Mar 2021 at 18:48, Max Timonin >> wrote: >> >> Discussed with Petr privately. Proposal is: >> >> 1. The [Build] job runs without any checks. >> 2. There will be a new job [Sanity Checks], that runs all checks - >> checkstyle, licenses, javadoc, check-suites. >> 3. [Sanity Checks] runs in parallel with [Build]. >> 4. All TC jobs with tests depend on a result of the [Sanity Checks] > job. If >> the check job fails then a test job won't be started. >> 5. Users can disable the [Sanity Checks] job with a selector on the >> Parameters tab of custom TC build. >> >> If no one has objections I will create a JIRA ticket for that. >> >> >> On Wed, Mar 3, 2021 at 5:11 PM Max Timonin >> > wrote: >> >>> Hi Petr! My proposal is: >>> >>> 1. Create a parameter in [Build] TC suite - MAVEN_CHECKS, default > value is >>> "-Plicenses,checkstyle,check-licenses,check-test-suites". >>> 2. Use it in a command along with MAVEN_MODULES_STRING. >>> -U -Pall-java,all-scala,scala,lgpl,examples %MAVEN_CHECKS% >>> %MAVEN_MODULES_STRING% >>> >>> 3. Provide a global param for test suites >> "reverse.dep.MAVEN_CHECKS" > that >>> is possible to override in a custom build. If I understand it > correctly is >>> possible to do by editing the job [1]. >>> 4. This param should be represented to a user as a selector with 2 >>> options: >>> - default (see point 1.) >>> - "-DskipTests=true" - that ignores all checks, skip tests and >> just > build >>> a .zip of Ignite. >>> >>> Could you please review this solution? Is it OK for you? >>> >>> [1] >>> > >> https://ci.ignite.apache.org/admin/editBuildParams.html?id=template:IgniteTests24Java8_RunTestSuitesJava >>> >>> On Thu, Feb 25, 2021 at 1:47 PM Petr Ivanov >> > wrote: >>> If profile can handle this — its ok. For choosing build type — we can introduce select, that will >> choose between -p and -DskipTests=true (defaulting to >> profile). Thus [Build] will pass either way. Regards, Petr Ivanov Head of IT IT & Development Solutions | GRIDGAIN SYSTEMS +7 (911) 945-00-59 > On 25 Feb 2021, at 13:23, Max Timonin >> > wrote: > > Yes, it's correct that "mvn install" runs also the "mvn test" > command, and > this is OK as the check-test-suites profile handles all tests > without running them. If the skipTests flag is triggered then >> this check is > useless. It will take only about 2 min to run "mvn test" with >> this profile. > Travis does that as one of steps. > > So, there are no issues with tests. Should I provide more info >> how > this > check works? > > Also, discussed with Anton Vinogradov, Alex Plekhanov. There >> can > be an > issue, that sometimes it's required to run custom test suites >> to > debug
