[VOTE] [RESULT] Release Extensions Ignite Spark 2.0.0 RC1 Ignite Spark 3.0.0 RC1

[Alexandr Shapkin]

Hello, Igniters!

The Ignite Spark 2.0.0 RC1 and Ignite Spark 3.0.0 RC1 extensions have been 
accepted.

5 - "+1" votes received.

Here are the +1 votes received:

- Nikita Amelchev
- Andrey Gura  (binding)
- Maxim Muzafarov (binding)
- Pavel Tupitsyn (binding)
- Slava Koptilin (binding)

Here is the link to the voting thread -
https://lists.apache.org/thread/6ktpkt751jd274wnnjsdpmdxdsk25lcb

[VOTE] Release Extensions Ignite Spark 2.0.0 RC1, Ignite Spark 3.0.0 RC1

[Alexandr Shapkin]

Dear Community,


The release candidates are ready.

These are new Ignite Spark integrations based on Spark 2.4 and 3.2 dependencies 
respectively.


See the links below.


== Ignite Spark Extension Module 2.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-2.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-2.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/actions/runs/3652976657



== Ignite Spark Extension Module 3.0.0 ==

The release candidate is uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-3.0.0-rc1/

The following Maven staging can be used:
https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/

Tag:
https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-3.0.0-rc1

RELEASE_NOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt

DEVNOTES:
https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/DEVNOTES.md

Release Checker Results:
https://github.com/apache/ignite-extensions/actions/runs/3634524603



The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept (Ignite Spark 3.0.0 RC1, Ignite Spark 2.0.0 RC1)
0 - don't care either way
-1 - DO NOT accept (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 for at least 72 hours till Mon Dec, 12 2022, 02:00 CET 
TZ. 
Please, write down the thread if you need additional time to check the release.

Re: ignite-spark3.2-ext release

[Alexandr Shapkin]

Hi Maxim,

Sounds good, I’m going to create the branches and start the process.

Could you please elaborate about what changes in DEVNOTES you are taking about? 



> On 7 Nov 2022, at 11:41, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> I can help with releasing this module (and actually it's pretty easy
> to do a release using GA), but I have some notes according to
> contribution:
> 
> 1. We should merge spark3.2-ext and spark-ext and separate development
> streams of different versions using branches with appropriate spark
> versions in them (like we do it before). For instance,
> ignite-spark-3.2 branch with 3.2 version etc. You can find an example
> with the following branches [1][2].
> 
> 2. We should update DEVNOTES with the release actions that should be
> performed using GA (I can do it).
> 
> 
> I would not be able to verify that everything works with spark 3.2
> integration, but I can help with the release.
> 
> WDYT?
> 
> 
> [1] 
> https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-4.2.0
> [2] 
> https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-5.1.0
> 
> On Mon, 7 Nov 2022 at 08:15, Ivan Gagarkin  wrote:
>> 
>> Hi Alexandr,
>> I would be glad if you can.
>> Not sure about all information. Vladimir Pligin has more details.
>> Right, no progress.
>> 
>> On Fri, 4 Nov 2022 at 02:12, Alexandr Shapkin  wrote:
>> 
>>> Hi Ivan,
>>> 
>>> I’d like to help with that. Is all release-related information described
>>> in the DEVNOTES?
>>> 
>>> I suppose there has not been any progress on the release since your
>>> initial message, correct?
>>> 
>>>> On 26 Oct 2022, at 09:05, Ivan Gagarkin  wrote:
>>>> 
>>>> Hi, Igniters
>>>> ignite-spark3.2-ext is ready for release. We have to make some steps to
>>> do
>>>> that:
>>>> 
>>>>  - Create a branch
>>>>  - Run some jobs on github
>>>> 
>>>> https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md
>>>> Who can help me with that?
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best Regards, Ivan
>>> 
>>> 
>> 
>> --
>> С уважением, Гагаркин И.Ю.

Re: ignite-spark3.2-ext release

[Alexandr Shapkin]

Hi Ivan,

I’d like to help with that. Is all release-related information described in the 
DEVNOTES? 

I suppose there has not been any progress on the release since your initial 
message, correct?

> On 26 Oct 2022, at 09:05, Ivan Gagarkin  wrote:
> 
> Hi, Igniters
> ignite-spark3.2-ext is ready for release. We have to make some steps to do
> that:
> 
>   - Create a branch
>   - Run some jobs on github
> 
> https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md
> Who can help me with that?
> 
> 
> 
> -- 
> Best Regards, Ivan

Re: [RESULT][VOTE] Release Apache Ignite 2.11.0 RC2

[Alexandr Shapkin]

Hello!

Since the new release comes with more modules extracted into the extensions 
repo, I think it’s vital to update them as well. Consider 
SpringTransactionManager which is now a part of ignite-spring-tx-ext [1] that 
hasn’t been released yet. At least I failed to find any maven artifacts 
published. Am I missing something?

[1] - 
https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-tx#maven-configuration


> On 23 Sep 2021, at 18:49, Dmitry Pavlov  wrote:
> 
> Thanks to Maxim and kudos to Alexey Gidaspov, who was serving role of Release 
> manager during all init, rampdown and stabilization phase. 
> 
> Sincerely,
> Dmitriy Pavlov
> 
> On 2021/09/21 09:01:55, Pavel Tupitsyn  wrote: 
>> Maxim,
>> 
>> I'll prepare a dedicated blog post about Ignite.NET changes later this week.
>> Thanks for driving the release!
>> 
>> On Mon, Sep 20, 2021 at 11:20 PM Maxim Muzafarov  wrote:
>> 
>>> Denis,
>>> 
>>> The post is added:
>>> https://blogs.apache.org/ignite/entry/apache-ignite-2-11-stabilization
>>> 
>>> I've fixed the image according to your suggestions.
>>> 
>>> On Mon, 20 Sept 2021 at 21:35, Denis Magda  wrote:
 
 Maxim, thanks for driving the release and preparing the announcement
 article!
 
 A few questions:
 
   - Should "dev" be replaced with "2.11" on the picture of the cellular
   clusters deployment section?
   - Will the article be published on our blogs.apache.org page?
 
 -
 Denis
 
 
 On Sat, Sep 18, 2021 at 9:36 PM Maxim Muzafarov 
>>> wrote:
 
> Pavel,
> 
> 
> I've prepared a draft blog post [1] for the 2.11 release announcement
> message, however, this post doesn't include changes related to the
> .NET part of the Apache Ignite. Will you prepare a dedicated post
> related to the .NET changes or I should include them in this one?
> 
> Folks,
> all the comments are welcome.
> 
> 
> [1]
> 
>>> https://github.com/Mmuzaf/mmuzaf.github.io/blob/main/_post/Release_Newsletter_211.md
> 
> 
> On Thu, 16 Sept 2021 at 17:21, Maxim Muzafarov 
>>> wrote:
>> 
>> Hello, Igniters!
>> 
>> Apache Ignite 2.11.0 release (RC2) has been accepted.
>> 
>> 5 - "+1" votes received.
>> 1 - "+0,5" vote received.
>> 
>> Here are the votes received:
>> 
>> - Pavel Tupitsyn (binding)
>> - Alex Plehanov (binding)
>> - Nikolay Izhikov (binding)
>> - Ilya Kasnacheev
>> - Ivan Daschinsky
>> - Zhenya Stanilovsky
>> 
>> 
>> Here is the link to the voting thread -
>> 
> 
>>> https://lists.apache.org/thread.html/rab233aa7d737b84b678fb74c81a867e3aad270471a2aac85a4d35cb8%40%3Cdev.ignite.apache.org%3E
>> 
>> Thank you!
> 
>>> 
>> 

Re: [ANNOUNCE] Apache Ignite spring-data-all-ext extensions 1.0.0 released

[Alexandr Shapkin]

Hello!

It looks like not all extensions have been published for the time being. This 
is somewhat important with respect to the new Ignite 2.11 release which doesn’t 
have corresponding extensions, in particular - ignite-spring-tx-ext meaning 
that official documentation [1] is lying a bit.


[1] - 
https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-tx#maven-configuration


> On 23 Aug 2021, at 14:33, Nikita Safonov  wrote:
> 
> Hi folks,
> 
> I've updated the docs. Please see the ticket and PR below:
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-15363
> [2] https://github.com/apache/ignite/pull/9350
> 
> Please merge it to master and port it to 2.10 and 2.11.
> 
> Thank you!
> 
> Regards,
> Nikita
> 
> чт, 29 июл. 2021 г. в 12:15, Nikita Safonov :
> 
>> Hi guys,
>> 
>> I can help with documenting this.
>> 
>> Is there a ticket for updating the Apache Ignite with Spring Data
>> 
>> docs ticket?
>> 
>> Regards,
>> Nikita
>> 
>> вт, 27 июл. 2021 г. в 17:01, Denis Magda :
>> 
>>> Nikita, thanks for releasing the artifacts.
>>> 
>>> Could you please update the following documentation section as well?
>>> 
>>> https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#maven-configuration
>>> 
>>> This is what worked for me:
>>> 
>>> 1. Ignite Spring Data dependency
>>> 
>>> 
>>>   org.apache.ignite
>>>   ignite-spring-data-2.2-ext
>>>   1.0.0
>>> 
>>> 
>>> 2. Also, I had to provide this dependency to solve various runtime-related
>>> issues (didn't need to do this with previous version of the integration):
>>> 
>>> 
>>>org.springframework.data
>>>spring-data-commons
>>>   * 2.2.3.RELEASE (this is hardcoded, needs to be
>>> generic in the docs)*
>>> 
>>> 
>>> --
>>> Denis
>>> 
>>> 
>>> -
>>> Denis
>>> 
>>> On Sat, Jul 24, 2021 at 7:46 PM Nikita Amelchev 
>>> wrote:
>>> 
 Hi,
 
 Artifacts were uploaded to the maven repo [1, 2, 3, 4].
 
 The spring-tx module was migrated in the 2.11 that was not released yet.
 The extension release is independent of the Ignite release.
 
 [1]
 
>>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-ext
 [2]
 
 
>>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-2.0-ext
 [3]
 
 
>>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-2.2-ext
 [4]
 
 
>>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-commons
 
 
 сб, 24 июл. 2021 г., 04:48 18624049226 <18624049...@163.com>:
 
> Igniters,
> 
> It seems that these artifact have not been uploaded to Maven Repo?
>>> Will
> it be uploaded with ignite 2.11?
> 
> This release does not include spring-tx-ext, but the documentation of
> this artifact has been merged into the ignite-2.11 branch, What's
>>> wrong?
> 
> 在 2021/7/7 下午1:49, Nikita Amelchev 写道:
>> The Apache Ignite Community is pleased to announce the release of
>> Apache Ignite Spring Data extensions 1.0.0.
>> 
>> The following integrations were migrated to the Apache Ignite
>> Extensions repository:
>> 
>> - Spring Data 2.2 extension.
>> - Spring Data 2.0 extension.
>> - Spring Data extension.
>> 
>> Release notes:
>> 
> 
 
>>> https://ignite.apache.org/releases/ext/spring-data-all-1.0.0/release_notes.html
>> 
>> The sources package is available here:
>> 
> 
 
>>> https://downloads.apache.org/ignite/ignite-extensions/ignite-spring-data-all-ext/1.0.0/
>> 
>> Please let us know if you have any problems
>> https://ignite.apache.org/community/resources.html#ask
>> 
> 
 
>>> 
>> 

[jira] [Created] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-14324:
-

 Summary: EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
 Key: IGNITE-14324
 URL: https://issues.apache.org/jira/browse/IGNITE-14324
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.11


Scenario:

Kubernetes world, a server node, a k8s service, and a thick client. The client 
is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected to the 
server node.

When a service goes down alongside the server, no EVT_CLIENT_NODE_DISCONNECTED 
is caught and the client reports only about a socket exception and inability to 
resolve IP addresses from the services, cause k8s resource is not available. 
The DEBUG logs (attached) show that discovery is constantly trying to use 
KubernetesIpFinder and restore the connection.

Expected:
Discovery realizes that a client is disconnected, no more reconnection attempts 
happen and EVT_CLIENT_NODE_DISCONNECTED is thrown.

Solution:

Count resolution attempts and if it’s more than the threshold (2 if 
failuredetectiontimeout is not configured, otherwise #reconnCount) give up and 
invoke disconnection logic



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

[jira] [Created] (IGNITE-13822) NPE in SQL query [with xxx as (select xxx)]

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-13822:
-

 Summary: NPE in SQL query [with xxx as  (select xxx)]
 Key: IGNITE-13822
 URL: https://issues.apache.org/jira/browse/IGNITE-13822
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.9
Reporter: Alexandr Shapkin


We use '*with xxx as  (select xxx)* ', which works very fine in 2.8.1 and other 
past release versions. After we upgrade to 2.9.0, such SQL starts to throw an 
exception.

Note, the SQL works fine while Ignite just started. The error happens after 
Ignite runs a while. And after that, the error seems to happen every time. 

 
{code:java}
args=Object[] [], stmtType=SELECT_STATEMENT_TYPE, autoCommit=true,
partResReq=false, super=JdbcRequest [type=2, reqId=790418]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to parse query. General error: "java.lang.NullPointerException" [5-197]
   at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:194)
   at
org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
   at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:355)
   at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:222)
   at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
   at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1071)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2779)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2775)
   at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3338)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$2(GridQueryProcessor.java:2795)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2833)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2769)
   at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2727)
   at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:647)
   at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:320)
   at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
   at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
   at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
   at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
   at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
   at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
   at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
   at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
   at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   at java.lang.Thread.run(Thread.java:745)
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-197]
   at 
org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
   at org.h2.message.DbException.get(DbException.java:168)
   at org.h2.message.DbException.convert(DbException.java:307)
   at 
org.h2.message.DbException.toSQLException(DbException.java:280)
   at org.h2.message.TraceObject.logAndConvert(TraceObject.java:357)
   at 
org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:697)
   at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
   ... 26 more
Caused by: java.lang.NullPointerException

[jira] [Created] (IGNITE-13453) Docker: Change run.sh to call java directly

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-13453:
-

 Summary: Docker: Change run.sh to call java directly
 Key: IGNITE-13453
 URL: https://issues.apache.org/jira/browse/IGNITE-13453
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.8.1
Reporter: Alexandr Shapkin
Assignee: Ilya Murchenko
 Fix For: 2.9


ignite.sh is cumbersome in Docker as it creates the hassle with signals not 
being propagated but adds little value as most of what ignite.sh discovers 
about the system is known beforehand for our Docker images.

Let's replace ignite.sh call with direct java invocation.

 



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

[jira] [Created] (IGNITE-13160) .NET: wrong affinity key registration with AffinityKeyMapped attribute

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-13160:
-

 Summary: .NET: wrong affinity key registration with 
AffinityKeyMapped attribute
 Key: IGNITE-13160
 URL: https://issues.apache.org/jira/browse/IGNITE-13160
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Alexandr Shapkin


When QueryEntities is set alongside a custom key that utilizes the 
AffinityKeyMapped attribute, the field won't be taken into account for some 
reason. When QueryEntities configuration gets removed, all works fine, setting 
KeyConfiguration manually helps as well. At the same time, the BinaryType 
registration itself looks fine.

After the investigation, it turned out that affinityKey field is not being 
registered on cache registration, and null is being cached instead. Later on 
Ignite correctly tries to register a custom class as a key, but it's never 
being updated internally case the real value is already cached.

 

Reproducer (add to the AffinityTest.cs):
{code:java}
/// 
/// Tests AffinityKeyMapped attribute should map to the same partitions
/// for the same field value.
/// 
[Test]
public void TestCustomAffinity()
{
IIgnite g = Ignition.GetIgnite("grid-0");

var cacheCfg = new CacheConfiguration("mycache")
{
// Without QueryEntities tests passes.
QueryEntities = new List()
{
new QueryEntity(typeof(MyKey), typeof(int))
}
};
g.GetOrCreateCache(cacheCfg);

var key1 = new MyKey {Data = "data1", AffinityKey = 1};
var key2 = new MyKey {Data = "data2", AffinityKey = 1};

ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
}

public class MyKey
{
[QuerySqlField]
public string Data { get; set; }
[AffinityKeyMapped]
public long AffinityKey { get; set; }
}
{code}



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

[jira] [Created] (IGNITE-12385) .NET Thin Client: introduce ClusterGroup API

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-12385:
-

 Summary: .NET Thin Client: introduce ClusterGroup API
 Key: IGNITE-12385
 URL: https://issues.apache.org/jira/browse/IGNITE-12385
 Project: Ignite
  Issue Type: New Feature
  Components: thin client
Affects Versions: 2.7.6
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.9


We need to implement IClusterGroup API for thin clients.

Let's start with following methods:
 * IClusterGroup.ForDotNet()
 * IClusterGroup.ForAttributes()
 * IClusterGroup.GetNodes()



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

[jira] [Created] (IGNITE-12381) QueryParser: propagate H2 ErrorCode to IgniteSQLException

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-12381:
-

 Summary: QueryParser: propagate H2 ErrorCode to IgniteSQLException
 Key: IGNITE-12381
 URL: https://issues.apache.org/jira/browse/IGNITE-12381
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.7.6
Reporter: Alexandr Shapkin


QueryParser#parseH2 method generalizes all h2 error codes as 
IgniteQueryErrorCode.PARSING

Whereas the actual error code could be more specific, like 

[TABLE_OR_VIEW_NOT_FOUND_1|https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html#c42102]
 = 42102

Let's try to convert those codes into the appropriate IgniteQueryErrorCode 
values as well.



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

RE: Thin clients: WithExpiryPolicy

[Alexandr Shapkin]

Pavel,

I think that in some cases milliseconds could make sense, 
so I would like to keep the current precision. 

With this approach we will avoid unnecessary code changes as well as
keeping API in consistence with the thick client method and cacheConfiguration 
settings.


From: Pavel Tupitsyn
Sent: Saturday, October 19, 2019 9:20 PM
To: dev
Subject: Re: Thin clients: WithExpiryPolicy

Alexandr,

Sounds good to me.

Remaining question is - how do we serialize the expiry policy?
Thick client passes this to JNI as 3 int64 values (duration in
milliseconds).
But I don't think we need millisecond precision for expiration, so we could
pass seconds as float values (3*4 bytes).

Thoughts?

On Fri, Oct 18, 2019 at 8:21 PM Alexandr Shapkin  wrote:

> Pavel,
>
> Thanks for sharing your thoughts.
>
> Right now I see that 2 reserved bytes come with every cache request:
> cacheId and flags.
> The first one is obvious, but the second one is used only for java thin
> client with enabled KeepBinary mode.
>
> I think we could use the flags byte and write an expiration policy flag
> when required.
> Whenever the server sees that there is a request with expiration flag, we
> deserialize a policy and apply it to the request.
>
> From: Pavel Tupitsyn
> Sent: Friday, October 18, 2019 7:05 PM
> To: dev
> Subject: Re: Thin clients: WithExpiryPolicy
>
> Stateless approach looks a lot better to me.
>
> We have a choice:
> * Keep expiry policy on server and send an ID with every request (like a
> query cursor ID - 8 bytes)
> * Send full expiry policy with every expiry-enabled request (24 bytes - or
> maybe less? We should think about the format)
>
> Stateful approach will bring a lot of complexity if we consider Affinity
> Awareness [1] mechanism (and also automatic reconnect).
> We would have to keep ExpiryPolicyId for every server and choose the right
> one based on the affinity for every operation.
> This can easily negate any performance gain from saving 16 bytes.
>
> And there is always CacheConfiguration.ExpiryPolicyFactory, which allows us
> to set up default expiry policy.
>
> > things could get worse if we decided to add a few more WithSomething*
> methods
> I don't think this is a good argument - we should decide on case by case
> basis.
> Anyway, other With* methods don't have any parameters, so they carry only 1
> bit of information.
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
>
> On Fri, Oct 18, 2019 at 5:14 PM Alexandr Shapkin 
> wrote:
>
> > Igniters,
> >
> > I would like to add WithExpirePolicy support to thin clients. [1]
> > For a thick client, we can obtain a reference to a cache wrapper instance
> > and use cache API through it. At the same time, the thin client protocol
> is
> > stateless, we do not hold a reference to a cache but rather a cache name
> > identifier is used for a server to create an appropriate cache instance.
> >
> > We could extend the protocol as we did with WithKeepBinaryMethod:
> > every time we need to call some API on a cache with expiration, a
> > serialized ExpiryPolicy (additional 3*8 bytes) would be sent. This
> approach
> > works well, but things could get worse if we decided to add a few more
> > WithSomething* methods.
> >
> > Initially, I was thinking about introducing some state context to a
> > protocol, similar to a QueryCursor API. For instance, we can save an
> expire
> > policy configuration for the first call and use some hash value based on
> an
> > ExpiryPolicy for further calls, just as we do for cache names. I.e.
> > newCacheId = [cacheId, new AdditionalValues(expiryPolicyId, binaryModeId,
> > )] But this approach complicates logic and leads to additional memory
> > consumption.
> >
> > I think it's ok for now to use the first approach with ExpiryPolicy
> > serialization.
> > But any ideas are welcome.
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-9033
> >
> >
>
>

RE: Documents about C++/C#/.NET

[Alexandr Shapkin]

GridGain had released new documentation just a couple of weeks ago.
It should contain updated content with multilanguage examples.

Feel free to review the same article regarding eviction policies [1]
[1] 
https://www.gridgain.com/docs/8.7.6/developers-guide/memory-architecture/eviction-policies


From: 李玉珏@163
Sent: Monday, October 21, 2019 3:41 PM
To: dev@ignite.apache.org
Subject: Re: Documents about C++/C#/.NET

Hi Ilya,

Many simple problems, I have submitted suggest edits, and most of them 
have been accepted.

But for example, the following page:

https://apacheignite-net.readme.io/docs/eviction-policies

I believe that many of the contents are outdated and many links are invalid.

A lot of content on this page needs to be re edited. I think it is more 
appropriate for the original author to do this work, because he knows 
more about this aspect.

在 2019/10/21 下午8:00, Ilya Kasnacheev 写道:
> Hello!
>
> I think it is a good idea to refer to Java documentation on same topic and
> keed duplication of content to minimum.
>
> Please to not hesitate to suggest edits for main Ignite documentation on
> readme.io!
>
> Thank you for your effort!
>
> Regards,

RE: Thin clients: WithExpiryPolicy

[Alexandr Shapkin]

Pavel,
 
Thanks for sharing your thoughts.
 
Right now I see that 2 reserved bytes come with every cache request: cacheId 
and flags. 
The first one is obvious, but the second one is used only for java thin client 
with enabled KeepBinary mode.
 
I think we could use the flags byte and write an expiration policy flag when 
required. 
Whenever the server sees that there is a request with expiration flag, we 
deserialize a policy and apply it to the request.

From: Pavel Tupitsyn
Sent: Friday, October 18, 2019 7:05 PM
To: dev
Subject: Re: Thin clients: WithExpiryPolicy

Stateless approach looks a lot better to me.

We have a choice:
* Keep expiry policy on server and send an ID with every request (like a
query cursor ID - 8 bytes)
* Send full expiry policy with every expiry-enabled request (24 bytes - or
maybe less? We should think about the format)

Stateful approach will bring a lot of complexity if we consider Affinity
Awareness [1] mechanism (and also automatic reconnect).
We would have to keep ExpiryPolicyId for every server and choose the right
one based on the affinity for every operation.
This can easily negate any performance gain from saving 16 bytes.

And there is always CacheConfiguration.ExpiryPolicyFactory, which allows us
to set up default expiry policy.

> things could get worse if we decided to add a few more WithSomething*
methods
I don't think this is a good argument - we should decide on case by case
basis.
Anyway, other With* methods don't have any parameters, so they carry only 1
bit of information.

https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients


On Fri, Oct 18, 2019 at 5:14 PM Alexandr Shapkin  wrote:

> Igniters,
>
> I would like to add WithExpirePolicy support to thin clients. [1]
> For a thick client, we can obtain a reference to a cache wrapper instance
> and use cache API through it. At the same time, the thin client protocol is
> stateless, we do not hold a reference to a cache but rather a cache name
> identifier is used for a server to create an appropriate cache instance.
>
> We could extend the protocol as we did with WithKeepBinaryMethod:
> every time we need to call some API on a cache with expiration, a
> serialized ExpiryPolicy (additional 3*8 bytes) would be sent. This approach
> works well, but things could get worse if we decided to add a few more
> WithSomething* methods.
>
> Initially, I was thinking about introducing some state context to a
> protocol, similar to a QueryCursor API. For instance, we can save an expire
> policy configuration for the first call and use some hash value based on an
> ExpiryPolicy for further calls, just as we do for cache names. I.e.
> newCacheId = [cacheId, new AdditionalValues(expiryPolicyId, binaryModeId,
> )] But this approach complicates logic and leads to additional memory
> consumption.
>
> I think it's ok for now to use the first approach with ExpiryPolicy
> serialization.
> But any ideas are welcome.
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-9033
>
>

Thin clients: WithExpiryPolicy

[Alexandr Shapkin]

Igniters,

I would like to add WithExpirePolicy support to thin clients. [1]
For a thick client, we can obtain a reference to a cache wrapper instance and 
use cache API through it. At the same time, the thin client protocol is 
stateless, we do not hold a reference to a cache but rather a cache name 
identifier is used for a server to create an appropriate cache instance.

We could extend the protocol as we did with WithKeepBinaryMethod: 
every time we need to call some API on a cache with expiration, a serialized 
ExpiryPolicy (additional 3*8 bytes) would be sent. This approach works well, 
but things could get worse if we decided to add a few more WithSomething* 
methods.

Initially, I was thinking about introducing some state context to a protocol, 
similar to a QueryCursor API. For instance, we can save an expire policy 
configuration for the first call and use some hash value based on an 
ExpiryPolicy for further calls, just as we do for cache names. I.e. newCacheId 
= [cacheId, new AdditionalValues(expiryPolicyId, binaryModeId, )] But this 
approach complicates logic and leads to additional memory consumption.

I think it's ok for now to use the first approach with ExpiryPolicy 
serialization.
But any ideas are welcome.

[1] - https://issues.apache.org/jira/browse/IGNITE-9033

[jira] [Created] (IGNITE-12293) .NET thin client: config serialization should use OpCodes

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-12293:
-

 Summary: .NET thin client: config serialization should use OpCodes
 Key: IGNITE-12293
 URL: https://issues.apache.org/jira/browse/IGNITE-12293
 Project: Ignite
  Issue Type: Improvement
  Components: thin client
Affects Versions: 2.7.6
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.9


Thin client configuration could be partially serialized via 
ClientCacheConfigurationSerializer.java

But this #OpCode based serialization is limited only to .NET -> Java direction.

Let's use OpCodes as a default implementation for all supported platforms, this 
will help us to add a new configuration section only for a specific platform.



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

[jira] [Created] (IGNITE-12177) CPP: Add Java compute support

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-12177:
-

 Summary: CPP: Add Java compute support
 Key: IGNITE-12177
 URL: https://issues.apache.org/jira/browse/IGNITE-12177
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.7.5
Reporter: Alexandr Shapkin


Currently compute.h contains only platform-specific API declaration (C++).

But Ignite does allow a native Java task execution. This feature already has 
been implemented for .NET platform.

Lets port the same changes to C++ client (use PlatformCompute#OP_EXEC_NATIVE).

 

This would help us to create a workaround for a mixed platform cluster that 
requires a compute calls.

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

RE: Unsubscribe

[Alexandr Shapkin]

Hello,  

Please,  send an email to user-unsubscr...@ignite.apache.org and 
dev-unsubscr...@ignite.apache.org

More details https://ignite.apache.org/community/resources.html#mail-lists

From: Deepa Kolwalkar
Sent: Monday, September 16, 2019 12:37 PM
To: u...@ignite.apache.org; dev@ignite.apache.org
Subject: Unsubscribe

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

RE: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Alexandr Shapkin]

Alexey,

The changes already have been tested, so no TC problems expected.
If this is true, then we need just a few hours to merge them.

From: Alexey Goncharuk
Sent: Wednesday, September 11, 2019 6:03 PM
To: dev
Cc: Dmitriy Govorukhin; Anton Kalashnikov
Subject: Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

Alexandr,

I almost sent the vote email :) When do you expect the fix to be in master
and 2.7.6?

ср, 11 сент. 2019 г. в 17:38, Alexandr Shapkin :

> Folks,
>
> A critical bug was detected in .NET [1].
>
> I understand that it’s a little bit late, but I propose to include this
> issue into the release scope.
>
> PR is ready, currently waiting for a TC visa.
>
> Thoughts?
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-12163
>
>
> From: Alexey Goncharuk
> Sent: Monday, September 9, 2019 5:11 PM
> To: dev
> Cc: Dmitriy Govorukhin; Anton Kalashnikov
> Subject: Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)
>
> Igniters,
>
> I just pushed the last ticket to ignite-2.7.6 branch; looks like we are
> ready for the next iteration.
>
> Given that Dmitriy Pavlov will be unavailable till the end of this week, I
> will take over the release. TC re-run is started.
>
> чт, 5 сент. 2019 г. в 16:14, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com>:
>
> > Hi Igniters,
> >
> > I finished work on https://issues.apache.org/jira/browse/IGNITE-12127,
> fix
> > already in master and ignite-2.7.6
> >
> > On Wed, Sep 4, 2019 at 2:22 PM Dmitriy Govorukhin <
> > dmitriy.govoruk...@gmail.com> wrote:
> >
> > > Hi Alexey,
> > >
> > > I think that I will finish work on the fix tomorrow. Fix already
> > completed
> > > but I need to get VISA from TC bot.
> > >
> > > On Mon, Sep 2, 2019 at 8:27 PM Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > >> Folks, it looks like I was overly optimistic with the estimates for
> the
> > >> mentioned two tickets.
> > >>
> > >> Dmitriy, Anton,
> > >> Can you share your vision when the issues will be fixed? Perhaps, it
> > makes
> > >> sense to release 2.7.6 with the already fixed issues and schedule
> 2.7.7?
> > >> Neither of them is a regression, so it's ok to release 2.7.6 as it is
> > now.
> > >>
> > >> Thoughts?
> > >>
> > >> сб, 31 авг. 2019 г. в 11:37, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > >> >:
> > >>
> > >> > Yes, my bad, forgot to include the link. That's the one.
> > >> >
> > >> > пт, 30 авг. 2019 г. в 15:01, Maxim Muzafarov :
> > >> >
> > >> >> Alexey,
> > >> >>
> > >> >> Does the issue [1] is related to this [2] discussion on the
> > user-list?
> > >> >> If yes, I think it is very important to include these fixes to
> 2.7.6.
> > >> >>
> > >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12127
> > >> >> [2]
> > >> >>
> > >>
> >
> http://apache-ignite-users.70518.x6.nabble.com/Node-failure-with-quot-Failed-to-write-buffer-quot-error-td29100.html
> > >> >>
> > >> >> On Fri, 30 Aug 2019 at 14:26, Alexei Scherbakov
> > >> >>  wrote:
> > >> >> >
> > >> >> > Alexey,
> > >> >> >
> > >> >> > Looks like important fixes, better to include them.
> > >> >> >
> > >> >> > пт, 30 авг. 2019 г. в 12:51, Alexey Goncharuk <
> > >> >> alexey.goncha...@gmail.com>:
> > >> >> >
> > >> >> > > Igniters,
> > >> >> > >
> > >> >> > > Given that the RC1 vote did not succeed and we are still
> waiting
> > >> for
> > >> >> a few
> > >> >> > > minor fixes, may I suggest including these two tickest to the
> > 2.7.6
> > >> >> scope?
> > >> >> > >
> > >> >> > > https://issues.apache.org/jira/browse/IGNITE-12127
> > >> >> > > https://issues.apache.org/jira/browse/IGNITE-12128
> > >> >> > >
> > >> >> > > The first one has been already reported on the dev-list [1],
> the
> > >> >> second one
> > >> >> > > may cause

RE: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Alexandr Shapkin]

Folks, 

A critical bug was detected in .NET [1].

I understand that it’s a little bit late, but I propose to include this issue 
into the release scope.

PR is ready, currently waiting for a TC visa. 

Thoughts?

[1] - https://issues.apache.org/jira/browse/IGNITE-12163


From: Alexey Goncharuk
Sent: Monday, September 9, 2019 5:11 PM
To: dev
Cc: Dmitriy Govorukhin; Anton Kalashnikov
Subject: Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

Igniters,

I just pushed the last ticket to ignite-2.7.6 branch; looks like we are
ready for the next iteration.

Given that Dmitriy Pavlov will be unavailable till the end of this week, I
will take over the release. TC re-run is started.

чт, 5 сент. 2019 г. в 16:14, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com>:

> Hi Igniters,
>
> I finished work on https://issues.apache.org/jira/browse/IGNITE-12127, fix
> already in master and ignite-2.7.6
>
> On Wed, Sep 4, 2019 at 2:22 PM Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com> wrote:
>
> > Hi Alexey,
> >
> > I think that I will finish work on the fix tomorrow. Fix already
> completed
> > but I need to get VISA from TC bot.
> >
> > On Mon, Sep 2, 2019 at 8:27 PM Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Folks, it looks like I was overly optimistic with the estimates for the
> >> mentioned two tickets.
> >>
> >> Dmitriy, Anton,
> >> Can you share your vision when the issues will be fixed? Perhaps, it
> makes
> >> sense to release 2.7.6 with the already fixed issues and schedule 2.7.7?
> >> Neither of them is a regression, so it's ok to release 2.7.6 as it is
> now.
> >>
> >> Thoughts?
> >>
> >> сб, 31 авг. 2019 г. в 11:37, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> >> >:
> >>
> >> > Yes, my bad, forgot to include the link. That's the one.
> >> >
> >> > пт, 30 авг. 2019 г. в 15:01, Maxim Muzafarov :
> >> >
> >> >> Alexey,
> >> >>
> >> >> Does the issue [1] is related to this [2] discussion on the
> user-list?
> >> >> If yes, I think it is very important to include these fixes to 2.7.6.
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12127
> >> >> [2]
> >> >>
> >>
> http://apache-ignite-users.70518.x6.nabble.com/Node-failure-with-quot-Failed-to-write-buffer-quot-error-td29100.html
> >> >>
> >> >> On Fri, 30 Aug 2019 at 14:26, Alexei Scherbakov
> >> >>  wrote:
> >> >> >
> >> >> > Alexey,
> >> >> >
> >> >> > Looks like important fixes, better to include them.
> >> >> >
> >> >> > пт, 30 авг. 2019 г. в 12:51, Alexey Goncharuk <
> >> >> alexey.goncha...@gmail.com>:
> >> >> >
> >> >> > > Igniters,
> >> >> > >
> >> >> > > Given that the RC1 vote did not succeed and we are still waiting
> >> for
> >> >> a few
> >> >> > > minor fixes, may I suggest including these two tickest to the
> 2.7.6
> >> >> scope?
> >> >> > >
> >> >> > > https://issues.apache.org/jira/browse/IGNITE-12127
> >> >> > > https://issues.apache.org/jira/browse/IGNITE-12128
> >> >> > >
> >> >> > > The first one has been already reported on the dev-list [1], the
> >> >> second one
> >> >> > > may cause a state when an Ignite node cannot start on existing
> >> >> persisted
> >> >> > > data. Looking at the tickets, the fixes should be reasonably
> easy,
> >> so
> >> >> it
> >> >> > > should not shift 2.7.6 release timeline much.
> >> >> > >
> >> >> > > Thoughts?
> >> >> > >
> >> >> > > ср, 28 авг. 2019 г. в 15:25, Nikolay Izhikov <
> nizhi...@apache.org
> >> >:
> >> >> > >
> >> >> > > > Separate repos for different Spark version is a good idea for
> me.
> >> >> > > > Anyway, can you help with Spark version migration,  for now?
> >> >> > > >
> >> >> > > > В Ср, 28/08/2019 в 15:20 +0300, Alexey Zinoviev пишет:
> >> >> > > > > Maybe the best solution today add for each new version of
> Spark
> >> >> the
> >> >> > > > > sub-module (Spark-2.3, Spark-2.4) or the separate repository
> >> with
> >> >> > > modules
> >> >> > > > > for each version or another way with separate repository and
> >> >> different
> >> >> > > > > branches like in
> >> >> > > https://github.com/datastax/spark-cassandra-connector
> >> >> > > > >
> >> >> > > > > 3 ways to support different versions with the different costs
> >> of
> >> >> > > support
> >> >> > > > >
> >> >> > > > > In the case of separate repository I could help, for example
> >> >> > > > >
> >> >> > > > > ср, 28 авг. 2019 г. в 14:57, Nikolay Izhikov <
> >> nizhi...@apache.org
> >> >> >:
> >> >> > > > >
> >> >> > > > > > Hello, Alexey.
> >> >> > > > > >
> >> >> > > > > > > But the
> >> >> > > > > > > compatibility with Spark 2.3 will be broken, isn't it?
> >> >> > > > > >
> >> >> > > > > > Yes.
> >> >> > > > > >
> >> >> > > > > > > Do you have any
> >> >> > > > > > > plans to support the different version of Spark without
> >> >> loosing
> >> >> > > your
> >> >> > > > > >
> >> >> > > > > > unique
> >> >> > > > > > > expertise in Spark-Ignite integration?
> >> >> > > > > >
> >> >> > > > > > What do you mean by "my unique expertise"? :)
> >> >> > > > > >
> >> >> > > 

[jira] [Created] (IGNITE-12163) CacheEntryEventType.Removed is not being rised

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-12163:
-

 Summary: CacheEntryEventType.Removed is not being rised
 Key: IGNITE-12163
 URL: https://issues.apache.org/jira/browse/IGNITE-12163
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.7.5
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin


Steps to reproduce:
 * Create a cache with user-defined type

 * Add an ICacheEntryEventListener in order to be notified of 
CacheEntryEventType.Removed events

 * Put a value in the cache

 * Remove that value

Expected: CacheEntryEventType.Removed event get captured
Actual: CacheEntryEventType.Updated event get captured

Update:
After these changes https://issues.apache.org/jira/browse/IGNITE-8714
New logic of detecting events (ContinuousQueryUtils.cs) now relies on the 
Object.Equals method which is not intuitive at all.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-11999) .NET unable to specify JvmDllPath for standalone node

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11999:
-

 Summary: .NET unable to specify JvmDllPath for standalone node
 Key: IGNITE-11999
 URL: https://issues.apache.org/jira/browse/IGNITE-11999
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.7.5
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.8


We have a -JvmDllPath CLI parameter/Ignite.JvmDllPath xml config for standalone 
nodes, that should take care about JVM dll location configuration.

This parameter won't work since Apache.Ignite.Config.Configurator expects 
another one:

/** Command line argument: Path to JVM dll. */
 private const string CmdJvmDll = "JvmDll";

 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-11984) .NET CompiledQuery won't work with strings

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11984:
-

 Summary: .NET CompiledQuery won't work with strings
 Key: IGNITE-11984
 URL: https://issues.apache.org/jira/browse/IGNITE-11984
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.7.5
Reporter: Alexandr Shapkin


Consider two samples:

var cache = GetClientCache();
 var persons = cache.AsCacheQueryable();

 

This works:

var qry = CompiledQuery.Compile((int id) => persons.Where(x => x.Value.Id == 
id));

 

This won't:

var qry = CompiledQuery.Compile((string id) => persons.Where(x => 
x.Value.Name.Equals(id)));

 

Error compiling query: entire LINQ expression should be specified within lambda 
passed to Compile method.

 

Reason: 

GetCompiledQuery method -> var paramValues becomes null

Because of that CacheQueryExpressionVisitor -> VisitConstant will not be 
executed

 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

RE: Signing off Ignite for export beyond the U.S.

[Alexandr Shapkin]

>1) Declaring older versions of Ignite.
>2) Is it correct to mention that Ignite uses .NET core controlled by  .NET
>Foundation? E.g. as follows:
>(controlled by)
>.NET Foundation
>title=Designed to use .NET Framework Cryptography Model
>href=https://dotnetfoundation.org/projects

>Should it go instead of Microsoft? Should we mention .NET code in addition
>to Microsoft?

Yes, I think we can do this. Ignite targets both of the them. And .NET Core 
uses it’s own implementation of standard class library[1]
Pavel may correct me.

[1] https://github.com/dotnet/corefx

From: Dmitriy Pavlov
Sent: Monday, June 17, 2019 4:35 PM
To: dev
Cc: Denis Magda; Igor Sapego; Pavel Petroshenko; Nikolay Izhikov
Subject: Re: Signing off Ignite for export beyond the U.S.

Thanks, Pavel!

Denis, Pavel, Igniters, please review the following proposal:

- Python, Node JS, ODBC to be declared as OpenSSL usage.
- AWS-S3 client-side encryption to be declared as JCA/JCE usage.
- SSLContextFactory usage to be declared as JCA/JCE usage.
- TDE to be declared as JCA/JCE

Export matrix data to be published in ASF-level SVN:
<
Product Name
Apache Ignite

Versions
development
2.7 and later 

ECCN
5D002

Controlled source
ASF
title=Designed to use with built-in Java Cryptography Architecture (JCA)
href=https://gitbox.apache.org/repos/asf?p=ignite.git

Oracle
title=Designed to use with built-in Java encryption libraries (JCE)
href=https://www.oracle.com/technetwork/java/javase/downloads/index.html

The OpenSSL Project
title=Designed to use General Purpose cryptography library included with
OpenSSL
href=https://www.openssl.org/source/

Microsoft
title=Designed to use .NET Framework Cryptography Model
href=https://dotnet.microsoft.com/download
>>

Open questions:
1) Declaring older versions of Ignite.
2) Is it correct to mention that Ignite uses .NET core controlled by  .NET
Foundation? E.g. as follows:
(controlled by)
.NET Foundation
title=Designed to use .NET Framework Cryptography Model
href=https://dotnetfoundation.org/projects

Should it go instead of Microsoft? Should we mention .NET code in addition
to Microsoft?

Sincerely,
Dmitriy Pavlov

пн, 17 июн. 2019 г. в 16:07, Pavel Tupitsyn :

> Hi Denis,
>
> Ignite.NET uses .NET Framework Standard Library for all security and
> cryptographic related code. There are no dependencies on external
> libraries.
>
> Thanks
>
> ср, 12 июн. 2019 г., 21:07 Denis Magda :
>
> > Igniters,
> >
> > Regardless of the fact that Ignite is an open source software, ASF as an
> > entity based in the U.S. has to comply with certain exporting regulations
> > [1].
> >
> > Dmitry Pavlov and I are working on adding Ignite to the table [2] of
> > projects allowed for export and might need the assistance of some of you.
> >
> > Here is a list of cryptographic functions used by Ignite (and provided by
> > a 3rd party vendor):
> >
> >1. JDK SSL/TLS libraries if a user wishes to enable secured
> >connectivity between cluster nodes. Manufacturer - Oracle/OpenJDK (
> >https://apacheignite.readme.io/docs/ssltls)
> >2. JDK AES/CBC/PKCS5Padding encryption from the Java libraries for
> >transparent data encryption of data on disk (
> >https://apacheignite.readme.io/docs/transparent-data-encryption)
> >3. Libraries/vendors for .NET nodes security?* Pavel Tupitsyn*, could
> >you check?
> >4. Libraries/vendors for C++ clients security (SSL, TLS, anything
> >else?). *Igor Sapego*, could you please check?
> >5. Libraries/vendors for Python, PHP, Node.JS SSL/TLS? *Dear thin
> >client contributors*, please facilitate.
> >6. Anything else missing from the list? We don't have any custom
> >crypto features, right?
> >
> > All of these usages/integrations have to comply with the following
> > checklist [3] before I, as a PMC Chair, submit a notice to Export
> > Administration Regulations of the U.S.A.
> >
> > [1] http://www.apache.org/licenses/exports/
> > [2] http://www.apache.org/licenses/exports/#matrix
> > [3] https://www.apache.org/dev/crypto.html#classify
> >
> >
> > -
> > Denis
> >
>

[jira] [Created] (IGNITE-11895) .NET Resharper inspections got broken after update

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11895:
-

 Summary: .NET Resharper inspections got broken after update
 Key: IGNITE-11895
 URL: https://issues.apache.org/jira/browse/IGNITE-11895
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.7
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin


Resharper Inspection add new violation after migration from 2018.1.4 to version 
2019.1
Lets suppress this new warning



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11893) .NET enum platform compatibility

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11893:
-

 Summary: .NET enum platform compatibility 
 Key: IGNITE-11893
 URL: https://issues.apache.org/jira/browse/IGNITE-11893
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.7
Reporter: Alexandr Shapkin


Let's make some warnings about platform compatibility.

[https://apacheignite-net.readme.io/docs/platform-interoperability]

We have a writeEnum/readEnum methods.

In java writeEnum can write only ordinal value, but in .NET we can assign any 
number to the enumValue. So any custom enum-to-primitive value binding would 
not be taken into account.

 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11805) .NET runnable core executable

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11805:
-

 Summary: .NET runnable core executable
 Key: IGNITE-11805
 URL: https://issues.apache.org/jira/browse/IGNITE-11805
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.8


Let's create a runnable .Net core executable similarly to Apache.Ignite.exe

This will helps us to start a server with a single dotnet command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11709) .NET thin client: introduce ClusterGroup methods

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11709:
-

 Summary: .NET thin client: introduce ClusterGroup methods
 Key: IGNITE-11709
 URL: https://issues.apache.org/jira/browse/IGNITE-11709
 Project: Ignite
  Issue Type: New Feature
  Components: thin client
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.8


Let's start implementing IClusterGroup methods for thin client.

Desired functionality, according  to the regular client
 * ForAttribute
 * ForCacheNodes
 * ForDotNet

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading

[Alexandr Shapkin (JIRA)]

Alexandr Shapkin created IGNITE-11690:
-

 Summary: .NET: Cache iteration hangs with enabled 
peerAssemblyLoading
 Key: IGNITE-11690
 URL: https://issues.apache.org/jira/browse/IGNITE-11690
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin


Solution to reproduce: 
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]

Given:
 * 2 server .NET nodes with PeerAssembly = enabled
 * Simple custom type cache with a few records 
{code:java}
ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new 
QueryEntity(typeof(Guid), typeof(Hotel;
{code}

 * 1 Client node that spawn computation task and performs a simple iteration 
over cache

 

 
{code:java}
class HelloAction : IComputeAction
{
[InstanceResource]
private IIgnite _ignite;

public void Invoke()
{
var hotels = _ignite.GetCache("SomeName").ToList()
 }
}
{code}
 

Problem:

 

One of the server nodes successfully performs the computation, but the other 
getting locked inside the 
{code:java}
AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
AssemblyRequest req)
{code}
When I disable PeerAssembly then all is getting back to normal

 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Hello

[Alexandr Shapkin]

Hello Ignite Community!
My name is Alexandr Shapkin. I want to contribute to Apache Ignite, my JIRA 
username is ashapkin. 
Thanks!