Re: NodeOrder in GridCacheVersion

[Alexei Scherbakov]

Hi Prasad.

nodeOrder is local counter used for updates ordering. The version is
incremented when lock is aquired for enlisted tx entry.

Are you sure where is no concurrent transaction on this replicated cache
which works significant time until committed ?
How long have you re-tried after getting optimistic exception ?
Do you have stable topology (no concurrently failing node) when this is
happens ?
Do you have on-heap cache enabled ?

чт, 27 февр. 2020 г. в 16:06, Prasad Bhalerao :

> Hi Alexey,
>
> Key value is not getting changed concurrently,  I am sure about it. The
> cache for which I am getting the exception is kind of bootstrap data and it
> changes very rarely. I have added retry logic in my code and it failed
> every time giving the same error .
>
> Every time if fails in GridDhtTxPrepareFuture.checkReadConflict ->
> GridCacheEntryEx.checkSerializableReadVersion method and I think it fails
> due to the change in value of nodeOrder. This is what I observed while
> debugging the method.
> This happens intermittently.
>
> I got following values while inspecting GridCacheVersion object on
> different nodes.
>
> Cache : Addons (Node 2)
> serReadVer of entry read inside Transaction: GridCacheVersion
> [topVer=194120123, order=4, nodeOrder=2]
> version on node3: GridCacheVersion [topVer=194120123, order=4, nodeOrder
> =1]
>
> Cache : Subscription  (Node 3)
> serReadVer of entry read inside Transaction:  GridCacheVersion
> [topVer=194120123, order=1, nodeOrder=2]
> version on node2:  GridCacheVersion [topVer=194120123, order=1, nodeOrder
> =10]
>
> Can you please answer following questions?
> 1) The significance of the nodeOrder w.r.t Grid and cache?
> 2) When does it change?
> 3) How it is important w.r.t. transaction?
> 4) Inside transaction I am reading and modifying Replicated as well as
> Partitioned cache. What I observed is this fails for Replicated cache. As
> workaround, I have moved the code which reads Replicated cache out of
> transaction block. Is it allowed to read and modify both replicated and
> Partitioned cache i.e. use both Replicated and Partitioned?
>
> Thanks,
> Prasad
>
> On Thu, Feb 27, 2020 at 6:01 PM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Prasad,
>>
>> Since optimistic transactions do not acquire key locks until prepare
>> phase, it is possible that the key value is concurrently changed before the
>> prepare commences. Optimistic exceptions is thrown exactly in this case and
>> suggest a user that they should retry the transaction.
>>
>> Consider the following example:
>> Thread 1: Start tx 1, Read (key1) -> val1
>> Thread 2: Start tx 2, Read (key2) -> val1
>>
>> Thread 1: Write (key1, val2)
>> Thread 1: Commit
>>
>> Thread 2: Write (key1, val3)
>> Thread 2: Commit *Optimistic exception is thrown here since current value
>> of key1 is not val1 anymore*
>>
>> When optimistic transactions are used, a user is expected to have a retry
>> logic. Alternatively, a pessimistic repeatable_read transaction can be used
>> (one should remember that in pessimistic mode locks are acquired on first
>> key access and released only on transaction commit).
>>
>> Hope this helps,
>> --AG
>>
>

-- 

Best regards,
Alexei Scherbakov

Excessive backups performance suggestion.

[Zhenya Stanilovsky]

Thank you guys for your comments, Anton i understand your proposal but i 
believe that highlighted case is rare and data safety is preferred.  I fill the 
ticket [1].
 
[1] https://issues.apache.org/jira/browse/IGNITE-12725  
>
>
>--- Forwarded message ---
>From: "Anton Vinogradov" < a...@apache.org >
>To:  dev@ignite.apache.org
>Cc: "Zhenya Stanilovsky" < arzamas...@mail.ru >
>Subject: Re: Excessive backups performance suggestion.
>Date: Thu, 06 Feb 2020 14:11:50 +0300
>
>>> most users do not want to lose data by default.
>But some ready to sacrifice.
>
>I know at least one case when "pure speed without insurance" required when
>the ML model is studying.
>
>On Thu, Feb 6, 2020 at 1:39 PM Alexei Scherbakov <
>alexey.scherbak...@gmail.com > wrote:
>
>> I'm quite sure most users do not want to lose data by default.
>>
>> It's not wise to recommend such thing even with explicit warning.
>>
>> чт, 6 февр. 2020 г. в 13:30, Anton Vinogradov < a...@apache.org >:
>>
>> > The statement seems to be correct for cases when we'd like to perform
>> fast
>> > loading and computation and not afraid of data loss.
>> > Performance boost always means we lose some guarantee.
>> > Let's just update the proposal with the explicit warning that reducing
>> > backups to zero may lead to data loss on any node failure.
>> >
>> > On Thu, Feb 6, 2020 at 1:09 PM Alexei Scherbakov <
>> >  alexey.scherbak...@gmail.com > wrote:
>> >
>> > > Definitely wrong recommendation.
>> > > Please file a ticket for removal.
>> > >
>> > > чт, 6 февр. 2020 г. в 12:26, Zhenya Stanilovsky
>> > < arzamas...@mail.ru.invalid
>> > > >:
>> > >
>> > > >
>> > > > Igniters, i found that suggesting zero backup for performance
>> > > improvements
>> > > > sounds like malicious and further problems suggestion. May be it`s
>> time
>> > > to
>> > > > remove it ?
>> > > >
>> > > > Example:
>> > > > [07:59:27] Performance suggestions for grid (fix if possible)
>> > > > [07:59:27] To disable, set
>> > -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
>> > > > [07:59:27] ^-- Decrease number of backups (set 'backups' to 0)
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > > Best regards,
>> > > Alexei Scherbakov
>> > >
>> >
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov 
 
 
 
 

[jira] [Created] (IGNITE-12725) Excessive backups performance suggestion.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12725:
---

 Summary: Excessive backups performance suggestion.
 Key: IGNITE-12725
 URL: https://issues.apache.org/jira/browse/IGNITE-12725
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.8
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Fix For: 2.8.1


I found that performance suggestion for zeroing backups count is incorrect in 
terms of proper cluster exploitation and easy way to loose your data. 
Discussion in dev list [1]. I suggest simple remove this message.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Excessive-backups-performance-suggestion-td45658.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Sergey Antonov]

Hello, Maxim!

All your links to ci.ignite.apache.org/ return 404 http code. It's okay?

чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov :

> Igniters,
>
>
> I've prepared everything to start a vote.
> Are we ready to go on?
>
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/
> https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/
>
> The following staging can be used for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1474/
>
> Tag with name 2.8.0-rc1 created:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
>
>
> TC [Check RC: Licenses, compile, chksum]
>
> https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv
>
> TC [3] Build & Upload Nuget Staging Packages
>
> https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv
>
> TC [2] Compare w/ Previous Release
>
> https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv
>
> On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn  wrote:
> >
> > Maxim,
> >
> > Fixes are in ignite-2.8 now, and builds have passed [1].
> > I think we can proceed.
> >
> > Thank you and sorry for the broken build.
> >
> > [1]
> >
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview
> >
> > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn 
> wrote:
> >
> > > I'm running a final check in branch ignite-2.8-dotnet-build-fix,
> should be
> > > done soon.
> > > After that I'll merge the changes into ignite-2.8 (and backport to
> > > master), and we can proceed.
> > >
> > > I had to fix both TC project and the build script.
> > > There were a few regressions introduced by various recent changes.
> > >
> > > > Can you also provide some details - which exactly artefacts should I
> > > check on staging resource after the [1] suite execution?
> > > We are supposed to verify that NuGet packages are valid by installing
> them
> > > and starting Ignite.
> > > However, we added an automatic check recently: `Run NuGet verification
> > > script` build step.
> > > So the only thing to check is that new package appears on MyGet [1]
> > > (scroll down to see versions and dates)
> > >
> > > [1]
> > >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> > >
> > >
> > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov 
> wrote:
> > >
> > >> Pavel,
> > >>
> > >>
> > >> Thank you for your help.
> > >> Please, let me know when I can proceed with a vote preparation.
> > >>
> > >>
> > >> Can you also provide some details - which exactly artefacts should I
> > >> check on staging resource after the [1] suite execution?
> > >>
> > >> [1]
> > >>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> > >>
> > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn 
> > >> wrote:
> > >> >
> > >> > Maxim, I did a quick fix for the script, but it did not work.
> > >> > Investigating further, will get back to you later today.
> > >> >
> > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov  >
> > >> wrote:
> > >> >>
> > >> >> Pavel,
> > >> >>
> > >> >>
> > >> >> Can you assist me with preparing NuGet staging according to the
> > >> >> release steps [1]? I've double-checked everything related to the
> build
> > >> >> but suite [2] for preparing nuget package still fails (sorry for
> > >> >> running it multiple times).
> > >> >>
> > >> >> I see some issues in the log which may be related to the file copy
> in
> > >> >> the build script which recently changed [4].
> > >> >> I'm still digging in, but anyway can you take a look and help?
> > >> >>
> > >> >>
> > >> >> Step 2:
> > >> >> Copy-Item : Cannot find path
> > >> >>
> > >>
> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because
> > >> >> it does not exist.
> > >> >>
> > >> >> Step 3:
> > >> >> Cannot find path
> > >> >>
> > >>
> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll'
> > >> >> because it does not exist.
> > >> >> At
> > >>
> C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283
> > >> >> char:47
> > >> >>
> > >> >> pack: invalid arguments.
> > >> >>
> > >> >>
> > >> >> [1]
> > >>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.4.2.PrepareNuGetstaging
> > >> >> [2]
> > >>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> > >> >> [3]
> > >>
> https://ci.ignite.apache.org/viewLog.html?buildId=5080553=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildLog
> > >> >> [4] 

Re: Node.JS, PHP, Python API references for Ignite 2.8 release

[Maxim Muzafarov]

Folks,

It seems that we have a lack of knowledge at the platforms README file [1].
Should we also update it?

[1] https://github.com/apache/ignite/blob/master/modules/platforms/README.txt

On Wed, 26 Feb 2020 at 21:42, Denis Magda  wrote:
>
> Igor Sapego, Igniters,
>
> I've been working on Ignite website improvements that will be introduced
> and contributed later and found that we still don't generate API references
> for Node.JS, PHP, Python. The APIs are not even shipped withing binary
> packages.
>
> Do our scripts for build/release generate those APIs? Can we start
> uploading them to the website under this path?
> https://svn.apache.org/repos/asf/ignite/site/trunk/releases
>
> -
> Denis

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Igniters,


I've prepared everything to start a vote.
Are we ready to go on?


I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/

The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1474/

Tag with name 2.8.0-rc1 created:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6


TC [Check RC: Licenses, compile, chksum]
https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv

TC [3] Build & Upload Nuget Staging Packages
https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv

TC [2] Compare w/ Previous Release
https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv

On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn  wrote:
>
> Maxim,
>
> Fixes are in ignite-2.8 now, and builds have passed [1].
> I think we can proceed.
>
> Thank you and sorry for the broken build.
>
> [1]
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview
>
> On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn  wrote:
>
> > I'm running a final check in branch ignite-2.8-dotnet-build-fix, should be
> > done soon.
> > After that I'll merge the changes into ignite-2.8 (and backport to
> > master), and we can proceed.
> >
> > I had to fix both TC project and the build script.
> > There were a few regressions introduced by various recent changes.
> >
> > > Can you also provide some details - which exactly artefacts should I
> > check on staging resource after the [1] suite execution?
> > We are supposed to verify that NuGet packages are valid by installing them
> > and starting Ignite.
> > However, we added an automatic check recently: `Run NuGet verification
> > script` build step.
> > So the only thing to check is that new package appears on MyGet [1]
> > (scroll down to see versions and dates)
> >
> > [1]
> > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> >
> >
> > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov  wrote:
> >
> >> Pavel,
> >>
> >>
> >> Thank you for your help.
> >> Please, let me know when I can proceed with a vote preparation.
> >>
> >>
> >> Can you also provide some details - which exactly artefacts should I
> >> check on staging resource after the [1] suite execution?
> >>
> >> [1]
> >> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> >>
> >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn 
> >> wrote:
> >> >
> >> > Maxim, I did a quick fix for the script, but it did not work.
> >> > Investigating further, will get back to you later today.
> >> >
> >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov 
> >> wrote:
> >> >>
> >> >> Pavel,
> >> >>
> >> >>
> >> >> Can you assist me with preparing NuGet staging according to the
> >> >> release steps [1]? I've double-checked everything related to the build
> >> >> but suite [2] for preparing nuget package still fails (sorry for
> >> >> running it multiple times).
> >> >>
> >> >> I see some issues in the log which may be related to the file copy in
> >> >> the build script which recently changed [4].
> >> >> I'm still digging in, but anyway can you take a look and help?
> >> >>
> >> >>
> >> >> Step 2:
> >> >> Copy-Item : Cannot find path
> >> >>
> >> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because
> >> >> it does not exist.
> >> >>
> >> >> Step 3:
> >> >> Cannot find path
> >> >>
> >> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll'
> >> >> because it does not exist.
> >> >> At
> >> C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283
> >> >> char:47
> >> >>
> >> >> pack: invalid arguments.
> >> >>
> >> >>
> >> >> [1]
> >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.4.2.PrepareNuGetstaging
> >> >> [2]
> >> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> >> >> [3]
> >> https://ci.ignite.apache.org/viewLog.html?buildId=5080553=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildLog
> >> >> [4] https://issues.apache.org/jira/browse/IGNITE-12604
> >> >>
> >> >> On Fri, 21 Feb 2020 at 10:36, Maxim Muzafarov 
> >> wrote:
> >> >> >
> >> >> > Denis,
> >> >> >
> >> >> >
> >> >> > Currently, we have no blockers. I'm preparing the build.
> >> >> >
> >> >> > On Thu, 20 Feb 2020 at 21:10, Denis Magda  wrote:
> >> >> > >
> >> >> > > Folks,
> >> >> > >
> >> >> > > Is there anything else apart from the open documentation tickets
> >> 

[jira] [Created] (IGNITE-12724) Command parser: do not skip commands with its own specific arguments

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-12724:


 Summary: Command parser: do not skip commands with its own 
specific arguments
 Key: IGNITE-12724
 URL: https://issues.apache.org/jira/browse/IGNITE-12724
 Project: Ignite
  Issue Type: Test
Reporter: Amelchev Nikita


{{CommandList.CACHE}}, {{CommandList.WAL}}, {{CommandList.SET_STATE}}, 
{{CommandList.ENCRYPTION}} commands have their own specific arguments. They are 
skipped in tests:
* testParseAndValidateSSLArguments
* testParseAndValidateUserAndPassword
* testConnectionSettings
Need to refactor tests and avoid skips:
{noformat}
if (skipCommand(cmd))
  continue;
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12723) Test refactoring. Explicit method to get MXBean instance

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12723:


 Summary: Test refactoring. Explicit method to get MXBean instance
 Key: IGNITE-12723
 URL: https://issues.apache.org/jira/browse/IGNITE-12723
 Project: Ignite
  Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


Test code contains several dozen of copy-paste code to get different MXBeans.
We can reduce code base by introducing common method for it.
Example of copy pasted code:

{code:java}

/** */
private FailureHandlingMxBean getMBean() throws Exception {
ObjectName name = U.makeMBeanName(getTestIgniteInstanceName(0), 
"Kernal",
FailureHandlingMxBeanImpl.class.getSimpleName());

MBeanServer srv = ManagementFactory.getPlatformMBeanServer();

assertTrue(srv.isRegistered(name));

return MBeanServerInvocationHandler.newProxyInstance(srv, name, 
FailureHandlingMxBean.class, true);
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [MTCGA]: new failures in builds [4974714] needs to be handled

[Pavel Tupitsyn]

Ivan, thank you, this is the answer:

>  it always fails when configured to run with Java 9 and higher

Ignite can only be built with Java 8, and NuGet project includes Java build
step, which fails.
I've fixed TC settings to force Java 8 for `Platform .NET (NuGet)` project,
it seems to fix the issue.

> 1. Does Ignite .NET work fine with java 9+?
Yes, it does

On Thu, Feb 27, 2020 at 2:25 PM Ivan Pavlukhin  wrote:

> Currently have no idea about ODBC (what suite is assumed?). Comparison
> success and failed NuGet runs shows that it always fails when
> configured to run with Java 9 and higher. No answers so far, but some
> questions I do not know answers for:
> 1. Does Ignite .NET work fine with java 9+?
> 2. Is it possible that NuGet job was always executed with java 8
> beforehand?
>
> Best regards,
> Ivan Pavlukhin
>
> вт, 18 февр. 2020 г. в 15:04, Igor Sapego :
> >
> > By the way, some ODBC tests became flaky about the same time as well.
> > May it be there is one root cause somewhere in SQL?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn 
> wrote:
> >
> > > I did a quick look some time ago, no idea what is going on, honestly.
> Tests
> > > became flaky for no apparent reason.
> > > I have this on my list, will investigate more.
> > >
> > > On Mon, Feb 17, 2020 at 8:43 PM Ivan Pavlukhin 
> > > wrote:
> > >
> > > > Looks like something broke .NET NuGet tests [1] in the end of
> January.
> > > > Is anyone working on it?
> > > >
> > > > [1]
> > > >
> > >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E=builds
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > пт, 31 янв. 2020 г. в 21:56, :
> > > > >
> > > > > 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 NuGet.ComputeTest
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3754909490222985251=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master NLogTest.TestIgniteStartup
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-557824718061284584=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *Recently contributed test failed in master NuGet.AspNetTest
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4468304894809184645=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master StartupTest.TestApacheIgniteExe
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5187257231705167662=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master
> > > > EntityFrameworkCacheTest.TestStartupPutGet
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4190667585576620977=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master StartupTest.TestSpringConfig
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6904015716462020548=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master StartupTest.TestCodeConfig
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-702135655943708515=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *Recently contributed test failed in master NuGet.CacheTest
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6551101028080942383=%3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master Log4NetTest.TestIgniteStartup
> > > >
> > >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4358661632507505081=%3Cdefault%3E=testDetails
> > > > >  Changes may lead to failure were done by
> > > > >  - aleksei scherbakov 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897229
> > > > >  - denis garus 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897244
> > > > >  - sergey chugunov 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897253
> > > > >  - anton kalashnikov 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897254
> > > > >  - ivan bessonov 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897233
> > > > >  - d.garus 
> > > > https://ci.ignite.apache.org/viewModification.html?modId=897266
> > > > >
> 

Re: NodeOrder in GridCacheVersion

[Prasad Bhalerao]

Hi Alexey,

Key value is not getting changed concurrently,  I am sure about it. The
cache for which I am getting the exception is kind of bootstrap data and it
changes very rarely. I have added retry logic in my code and it failed
every time giving the same error .

Every time if fails in GridDhtTxPrepareFuture.checkReadConflict ->
GridCacheEntryEx.checkSerializableReadVersion method and I think it fails
due to the change in value of nodeOrder. This is what I observed while
debugging the method.
This happens intermittently.

I got following values while inspecting GridCacheVersion object on
different nodes.

Cache : Addons (Node 2)
serReadVer of entry read inside Transaction: GridCacheVersion
[topVer=194120123, order=4, nodeOrder=2]
version on node3: GridCacheVersion [topVer=194120123, order=4, nodeOrder=1]

Cache : Subscription  (Node 3)
serReadVer of entry read inside Transaction:  GridCacheVersion
[topVer=194120123, order=1, nodeOrder=2]
version on node2:  GridCacheVersion [topVer=194120123, order=1, nodeOrder
=10]

Can you please answer following questions?
1) The significance of the nodeOrder w.r.t Grid and cache?
2) When does it change?
3) How it is important w.r.t. transaction?
4) Inside transaction I am reading and modifying Replicated as well as
Partitioned cache. What I observed is this fails for Replicated cache. As
workaround, I have moved the code which reads Replicated cache out of
transaction block. Is it allowed to read and modify both replicated and
Partitioned cache i.e. use both Replicated and Partitioned?

Thanks,
Prasad

On Thu, Feb 27, 2020 at 6:01 PM Alexey Goncharuk 
wrote:

> Prasad,
>
> Since optimistic transactions do not acquire key locks until prepare
> phase, it is possible that the key value is concurrently changed before the
> prepare commences. Optimistic exceptions is thrown exactly in this case and
> suggest a user that they should retry the transaction.
>
> Consider the following example:
> Thread 1: Start tx 1, Read (key1) -> val1
> Thread 2: Start tx 2, Read (key2) -> val1
>
> Thread 1: Write (key1, val2)
> Thread 1: Commit
>
> Thread 2: Write (key1, val3)
> Thread 2: Commit *Optimistic exception is thrown here since current value
> of key1 is not val1 anymore*
>
> When optimistic transactions are used, a user is expected to have a retry
> logic. Alternatively, a pessimistic repeatable_read transaction can be used
> (one should remember that in pessimistic mode locks are acquired on first
> key access and released only on transaction commit).
>
> Hope this helps,
> --AG
>

Java thin client errors handling

[Aleksandr Shapkin]

Hello!



I just noticed that the Java thin client throws the following internal
exceptions:

ClientProtocolError

ClientError



Since the classes are not public, there is no way to catch them properly in
user code.

Consider the recent changes, introduced by IGNITE-9410:



throw new ClientProtocolError(String.format("Transactions have not
supported by the server's " +

"protocol version %s, required version %s",
req.clientChannel().serverVersion(), V1_5_0));



The code above correctly verifies the server version against the current
client and throws an exception

In case of an outdated server. The only way to catch it in user code is by
RuntimeException

that feels too broad to use.



I’d like to discuss what’d be the best option to handle this scenario:

-Should we make the ClientError public?

-Should we introduce a new public error for every particular
exception?

-Just ignore this?



Thoughts?

-- 
Alex.

Re: NodeOrder in GridCacheVersion

[Alexey Goncharuk]

Prasad,

Since optimistic transactions do not acquire key locks until prepare phase,
it is possible that the key value is concurrently changed before the
prepare commences. Optimistic exceptions is thrown exactly in this case and
suggest a user that they should retry the transaction.

Consider the following example:
Thread 1: Start tx 1, Read (key1) -> val1
Thread 2: Start tx 2, Read (key2) -> val1

Thread 1: Write (key1, val2)
Thread 1: Commit

Thread 2: Write (key1, val3)
Thread 2: Commit *Optimistic exception is thrown here since current value
of key1 is not val1 anymore*

When optimistic transactions are used, a user is expected to have a retry
logic. Alternatively, a pessimistic repeatable_read transaction can be used
(one should remember that in pessimistic mode locks are acquired on first
key access and released only on transaction commit).

Hope this helps,
--AG

[jira] [Created] (IGNITE-12722) Get rid of GridCacheDatabaseSharedManager#getPageMemoryForCacheGroup functionality.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12722:
---

 Summary: Get rid of 
GridCacheDatabaseSharedManager#getPageMemoryForCacheGroup functionality.
 Key: IGNITE-12722
 URL: https://issues.apache.org/jira/browse/IGNITE-12722
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny


I found that {code:java}getPageMemoryForCacheGroup{code} with inner PageMemory 
casts can be easily removed.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12721) Validation of key length written to Distributed Metastorage

[Sergey Chugunov (Jira)]

Sergey Chugunov created IGNITE-12721:


 Summary: Validation of key length written to Distributed 
Metastorage
 Key: IGNITE-12721
 URL: https://issues.apache.org/jira/browse/IGNITE-12721
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.9


DistributedMetastorage functionality introduced in IGNITE-10640 provides 
convenient way to perform coordinated writes to local MetaStorages on all 
server nodes but lacks important part: validation of key length.

Current implementation of MetaStorage doesn't allow keys longer than a specific 
value (64 bytes minus some prefixes, see source code for details) and throws 
assertion error on an attempt to write longer key.

This error from MetaStorage is not propagated to DistributedMetastorage and (in 
theory) may even cause a node to halt.

In order to avoid this situation validation of key length should be added right 
to DistributedMetastorage implementation to enforce "fail-fast" principle and 
preserve Ignite nodes from potentially dangerous consequences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Fwd: NodeOrder in GridCacheVersion

[Prasad Bhalerao]

Hi Ilya, didn't get what are you trying to say.

The problem I am facing is, my transaction is failing giving
TransactionOptimisticException. I do not have a reproducer for this project
and this does not happen frequently.
Transaction is failing during prepare phase. I had to open a debug port on
all grid nodes to do remote  debugging in order to debug this issue.
What I observed is transaction fails because check in
GridCacheMapEntry.checkSerializableReadVersion fails as the nodeOrder in
GridCacheVersion in serialized version is different from the actual
noderOrder in GridCacheVersion of respective node. This method returns
false on 2 nodes out 4 nodes and this is happening for Replicated cache.

This is the reason I asked What is nodeOrder in GridCacheVersion and why it
is important while checking read entries in Transaction context?

I tried to debug nodeOrder in ignite code but could not understand it.

Inside transaction I am reading and modifying Replicated as well as
Partitioned cache. What I observed is this fails for Replicated cache. As
workaround, I have moved the code which reads Replicated cache out of
transaction block.
Is it allowed to read and modify both replicated and Partitioned cache i.e.
use both Replicated and Partition?

Complete exception can be found here
.

Thanks,
Prasad

On Thu, Feb 27, 2020 at 1:00 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> I don't think this is userlist discussion, this logging is not aimed at
> end-user and you are not supposed to act on it.
>
> Do you have any context for us, such as reproducer project or complete
> logs?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 26 февр. 2020 г. в 19:13, Prasad Bhalerao <
> prasadbhalerao1...@gmail.com>:
>
>> Can someone please advise?
>>
>> On Wed 26 Feb, 2020, 12:23 AM Prasad Bhalerao <
>> prasadbhalerao1...@gmail.com wrote:
>>
>>> Hi,
>>>
 Ignite Version: 2.6
 No of nodes: 4

 I am getting following exception while committing transaction.

 Although I just reading the value from this cache inside transaction
 and I am sure that the  cache and "cache entry" read is not being modified
 out this transaction on any other node.

 So I debugged the code and found out that it fails in following code on
 2 nodes out of 4 nodes.

 GridDhtTxPrepareFuture#checkReadConflict -
 GridCacheEntryEx#checkSerializableReadVersion

 GridCacheVersion version failing for equals check are given below for 2
 different caches. I can see that it failing because of change in nodeOrder
 of cache.

 1) Can some please explain the significance of the nodeOrder w.r.t Grid
 and cache? When does it change?
 2) How to solve this problem?

 Cache : Addons (Node 2)
 serReadVer of entry read inside Transaction: GridCacheVersion
 [topVer=194120123, order=4, nodeOrder=2]
 version on node3: GridCacheVersion [topVer=194120123, order=4,
 nodeOrder=1]

 Cache : Subscription  (Node 3)
 serReadVer of entry read inside Transaction:  GridCacheVersion
 [topVer=194120123, order=1, nodeOrder=2]
 version on node2:  GridCacheVersion [topVer=194120123, order=1,
 nodeOrder=10]


 *EXCEPTION:*

 Caused by:
 org.apache.ignite.internal.transactions.IgniteTxOptimisticCheckedException:
 Failed to prepare transaction, read/write conflict

>>>
>>>

 Thanks,
 Prasad

>>>

Re: [MTCGA]: new failures in builds [4974714] needs to be handled

[Ivan Pavlukhin]

Currently have no idea about ODBC (what suite is assumed?). Comparison
success and failed NuGet runs shows that it always fails when
configured to run with Java 9 and higher. No answers so far, but some
questions I do not know answers for:
1. Does Ignite .NET work fine with java 9+?
2. Is it possible that NuGet job was always executed with java 8 beforehand?

Best regards,
Ivan Pavlukhin

вт, 18 февр. 2020 г. в 15:04, Igor Sapego :
>
> By the way, some ODBC tests became flaky about the same time as well.
> May it be there is one root cause somewhere in SQL?
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn  wrote:
>
> > I did a quick look some time ago, no idea what is going on, honestly. Tests
> > became flaky for no apparent reason.
> > I have this on my list, will investigate more.
> >
> > On Mon, Feb 17, 2020 at 8:43 PM Ivan Pavlukhin 
> > wrote:
> >
> > > Looks like something broke .NET NuGet tests [1] in the end of January.
> > > Is anyone working on it?
> > >
> > > [1]
> > >
> > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E=builds
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > пт, 31 янв. 2020 г. в 21:56, :
> > > >
> > > > 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 NuGet.ComputeTest
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3754909490222985251=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master NLogTest.TestIgniteStartup
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-557824718061284584=%3Cdefault%3E=testDetails
> > > >
> > > >  *Recently contributed test failed in master NuGet.AspNetTest
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4468304894809184645=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master StartupTest.TestApacheIgniteExe
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5187257231705167662=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master
> > > EntityFrameworkCacheTest.TestStartupPutGet
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4190667585576620977=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master StartupTest.TestSpringConfig
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6904015716462020548=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master StartupTest.TestCodeConfig
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-702135655943708515=%3Cdefault%3E=testDetails
> > > >
> > > >  *Recently contributed test failed in master NuGet.CacheTest
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6551101028080942383=%3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master Log4NetTest.TestIgniteStartup
> > >
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4358661632507505081=%3Cdefault%3E=testDetails
> > > >  Changes may lead to failure were done by
> > > >  - aleksei scherbakov 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897229
> > > >  - denis garus 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897244
> > > >  - sergey chugunov 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897253
> > > >  - anton kalashnikov 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897254
> > > >  - ivan bessonov 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897233
> > > >  - d.garus 
> > > https://ci.ignite.apache.org/viewModification.html?modId=897266
> > > >
> > > >  - 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:56:42 31-01-2020
> > >
> >

RE: Configuring Ignite Thread Pool's Core thread count/max thread count/etc

[Sunny Chan, CLSA]

Just to make it clear, you prefer the option 1 in my suggestion? That is listed 
out all the potential configurable for thread pool for each thread pools in 
Ignite?

I do see that we have setDataStorageConfiguration where the parameters for data 
storage is grouped together into a configuration object, similar to my proposal 
2 –would that be better?

From: Ilya Kasnacheev 
Sent: Thursday, February 27, 2020 6:05 PM
To: Sunny Chan, CLSA 
Cc: dev 
Subject: Re: Configuring Ignite Thread Pool's Core thread count/max thread 
count/etc

Hello!

My suggestion is to use org.apache.ignite.configuration.IgniteConfiguration and 
avoid introducing your own classes, etc. Cut out the middle man.

Regards,
--
Ilya Kasnacheev


чт, 27 февр. 2020 г. в 05:36, Sunny Chan, CLSA 
mailto:sunny.c...@clsa.com>>:
Hi Ilya,

For the IgniteConfiguration interface, do we prefer:

1) IgniteConfiguration.setSystemThreadPoolCoreSize(), 
IgniteConfiguration.setSystemThreadPoolTimeOut(),IgniteConfiguration.setPublicThreadPoolCoreSize(),
 etc.
2) IgniteConfiguration.setSystemThreadPool(ThreadPoolConfiguration), 
IgniteConfiguration.setThreadPoolCoreSize(ThreadPoolConfiguration) and then we 
have ThreadPoolConfiguration.setCoreSize(), etc

Thanks.

-Original Message-
From: Ilya Kasnacheev 
mailto:ilya.kasnach...@gmail.com>>
Sent: Wednesday, February 26, 2020 6:10 PM
To: dev mailto:dev@ignite.apache.org>>
Subject: Re: Configuring Ignite Thread Pool's Core thread count/max thread 
count/etc

Hello!

We recommend exposing IgniteConfiguration for user to modify. You never know in 
advance what kind of tuning will be needed, and don't want to play chinese 
whispers game with your users.

Regards,
--
Ilya Kasnacheev


ср, 26 февр. 2020 г. в 13:07, Sunny Chan, CLSA 
mailto:sunny.c...@clsa.com>>:

> Hello,
>
>
>
> We are running Ignite cluster on bare metal on a relatively high core
> count machine (4x10 cores 20 threads), and looking some of the thread pool
> initialization code:
>
>
>
> (IgnitionEx.java)
>
> sysExecSvc = *new* IgniteThreadPoolExecutor(
>
> "sys",
>
> cfg.getIgniteInstanceName(),
>
> cfg.getSystemThreadPoolSize(),
>
> cfg.getSystemThreadPoolSize(),
>
> *DFLT_THREAD_KEEP_ALIVE_TIME*,
>
> *new* LinkedBlockingQueue(),
>
> GridIoPolicy.*SYSTEM_POOL*);
>
>
>
> Notice that the core thread pool size is equals to the max thread pool
> settings, which is by default same as the number of CPU cores. And in our
> cases, we won’t be reusing any threads until we have enough request coming
> in to fill 80 threads. Also, we might want to tune the thread keep alive
> time to improve thread reuse.
>
>
>
> We would like to propose to change ignite so that users can configure the
> core thread pool size in these Ignite thread pools. What is the best way to
> expose these parameters for user to modify?
>
>
>
> Would the ignite dev team prefer exposing individual core thread size and
> others (ie. cfg.get/setSystemThreadPoolCoreSize(),
> cfg.get/setSystemThreadPoolKeepAliveTime(), ..) or should we use a thread
> pool configuration object? (e.g.
> cfg.getSystemThreadPoolConfiguration(ThreadPoolConfiguration config) where
> ThreadPoolConfiguration has get and set methods for core thread pool size,
> etc)?
>
>
>
> *Sunny Chan*
>
> *Senior Lead Engineer, Executive Services*
>
> D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 
>
> 5/F, One Island East, 18 Westlands Road, Island East, Hong Kong
>
>
>
> [image: :1. Social Media Icons:CLSA_Social Media Icons_linkedin.png]
>   >[image: :1. Social Media
> Icons:CLSA_Social Media Icons_twitter.png]
>   >[image: :1. Social Media
> Icons:CLSA_Social Media Icons_youtube.png]
>   >[image: :1.
> Social Media Icons:CLSA_Social Media Icons_facebook.png]
>   >
>
>
>
> *clsa.com* 
>
> *Insights. Liquidity. Capital. *
>
>
>
> [image: CLSA_RGB] 

Re: Configuring Ignite Thread Pool's Core thread count/max thread count/etc

[Ilya Kasnacheev]

Hello!

My suggestion is to use org.apache.ignite.configuration.IgniteConfiguration
and avoid introducing your own classes, etc. Cut out the middle man.

Regards,
-- 
Ilya Kasnacheev


чт, 27 февр. 2020 г. в 05:36, Sunny Chan, CLSA :

> Hi Ilya,
>
> For the IgniteConfiguration interface, do we prefer:
>
> 1) IgniteConfiguration.setSystemThreadPoolCoreSize(),
> IgniteConfiguration.setSystemThreadPoolTimeOut(),IgniteConfiguration.setPublicThreadPoolCoreSize(),
> etc.
> 2) IgniteConfiguration.setSystemThreadPool(ThreadPoolConfiguration),
> IgniteConfiguration.setThreadPoolCoreSize(ThreadPoolConfiguration) and then
> we have ThreadPoolConfiguration.setCoreSize(), etc
>
> Thanks.
>
> -Original Message-
> From: Ilya Kasnacheev 
> Sent: Wednesday, February 26, 2020 6:10 PM
> To: dev 
> Subject: Re: Configuring Ignite Thread Pool's Core thread count/max thread
> count/etc
>
> Hello!
>
> We recommend exposing IgniteConfiguration for user to modify. You never
> know in advance what kind of tuning will be needed, and don't want to play
> chinese whispers game with your users.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 26 февр. 2020 г. в 13:07, Sunny Chan, CLSA :
>
> > Hello,
> >
> >
> >
> > We are running Ignite cluster on bare metal on a relatively high core
> > count machine (4x10 cores 20 threads), and looking some of the thread
> pool
> > initialization code:
> >
> >
> >
> > (IgnitionEx.java)
> >
> > sysExecSvc = *new* IgniteThreadPoolExecutor(
> >
> > "sys",
> >
> > cfg.getIgniteInstanceName(),
> >
> > cfg.getSystemThreadPoolSize(),
> >
> > cfg.getSystemThreadPoolSize(),
> >
> > *DFLT_THREAD_KEEP_ALIVE_TIME*,
> >
> > *new* LinkedBlockingQueue(),
> >
> > GridIoPolicy.*SYSTEM_POOL*);
> >
> >
> >
> > Notice that the core thread pool size is equals to the max thread pool
> > settings, which is by default same as the number of CPU cores. And in our
> > cases, we won’t be reusing any threads until we have enough request
> coming
> > in to fill 80 threads. Also, we might want to tune the thread keep alive
> > time to improve thread reuse.
> >
> >
> >
> > We would like to propose to change ignite so that users can configure the
> > core thread pool size in these Ignite thread pools. What is the best way
> to
> > expose these parameters for user to modify?
> >
> >
> >
> > Would the ignite dev team prefer exposing individual core thread size and
> > others (ie. cfg.get/setSystemThreadPoolCoreSize(),
> > cfg.get/setSystemThreadPoolKeepAliveTime(), ..) or should we use a thread
> > pool configuration object? (e.g.
> > cfg.getSystemThreadPoolConfiguration(ThreadPoolConfiguration config)
> where
> > ThreadPoolConfiguration has get and set methods for core thread pool
> size,
> > etc)?
> >
> >
> >
> > *Sunny Chan*
> >
> > *Senior Lead Engineer, Executive Services*
> >
> > D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 
> >
> > 5/F, One Island East, 18 Westlands Road, Island East, Hong Kong
> >
> >
> >
> > [image: :1. Social Media Icons:CLSA_Social Media Icons_linkedin.png]
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__hk.linkedin.com_company_clsa=DwIFaQ=lxzXOFU02467FL7HOPRqCw=9dPMIMeLdcqo3dX29zZZ4USXrC7gp_0p-Fvzzp2WzgU=cblNaj4j3LVM7Djyn0ffKyR3bThUEDp7iqqm5mRgkys=Yaq04TdZjYF0IXiRHXdbJS_fU_YNho-DXGuYjRNAfRM=
> >[image: :1. Social Media
> > Icons:CLSA_Social Media Icons_twitter.png]
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_clsainsights-3Flang-3Den=DwIFaQ=lxzXOFU02467FL7HOPRqCw=9dPMIMeLdcqo3dX29zZZ4USXrC7gp_0p-Fvzzp2WzgU=cblNaj4j3LVM7Djyn0ffKyR3bThUEDp7iqqm5mRgkys=60dVf5GhkOQ8CsuUVPmzqzQ3KBWI7Jl66i-gAajMqhw=
> >[image: :1. Social Media
> > Icons:CLSA_Social Media Icons_youtube.png]
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UC0qWp-5FlLnOcRYmBlCNQgZKA=DwIFaQ=lxzXOFU02467FL7HOPRqCw=9dPMIMeLdcqo3dX29zZZ4USXrC7gp_0p-Fvzzp2WzgU=cblNaj4j3LVM7Djyn0ffKyR3bThUEDp7iqqm5mRgkys=mDwljLI4KYkfMCIaiGVeezUNf52sbK8OLOj90ISnrOU=
> >[image: :1.
> > Social Media Icons:CLSA_Social Media Icons_facebook.png]
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_clsacommunity_=DwIFaQ=lxzXOFU02467FL7HOPRqCw=9dPMIMeLdcqo3dX29zZZ4USXrC7gp_0p-Fvzzp2WzgU=cblNaj4j3LVM7Djyn0ffKyR3bThUEDp7iqqm5mRgkys=FeoNstP309ftIhDxtwesvrG7_7h4hiVHichs7zv3_IQ=
> >
> >
> >
> >
> > *clsa.com* 
> >
> > *Insights. Liquidity. Capital. *
> >
> >
> >
> > [image: CLSA_RGB] 
> >
> >
> >
> > *A CITIC Securities Company*
> >
> >
> >
> > The content of this communication is intended for the recipient and is
> > subject to CLSA Legal and Regulatory Notices.
> > These can be viewed at https://www.clsa.com/disclaimer.html or sent to
> > you upon request.
> > Please consider before printing. CLSA is ISO14001 certified and committed
> > to reducing its impact on the environment.
> >
> The content 

[jira] [Created] (IGNITE-12720) .NET: CachePeekMode is not treated as Flags

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-12720:
---

 Summary: .NET: CachePeekMode is not treated as Flags
 Key: IGNITE-12720
 URL: https://issues.apache.org/jira/browse/IGNITE-12720
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


CachePeekMode is a [Flags] enum, but Ignite APIs such as ICache.GetSize take 
params array, and do not work when multiple flags are passed as one value with 
bitwise OR. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)