Re: Re[2]: IEP-58: Statistics

[Sasha Belyak]

Hello Zhenya,
First of all - local statistics are not useless cause we can use it in
local H2 query planning phase, at least for now.
"Client ..." - any node, that can build query execution plans. I believe
that lately we can do query execution planning on client nodes. But it's a
good question and I rename "client node" to "query planning node".
" If there are no statistics in all of them - client will choose random   "
- I suppose we can choose any server node that can hold data, covered by
requested statistics. But if query planning node needs statistics by two or
more tables - they can be located in a separate groups of server nodes so
such queries should be send separately. So the answer is yes (we should
send statistics request and collection request only to nodes, storing the
table) and no (collection request can be send to any of that node)
"After getting statistics client will cache it and server node it to renew
statistics from same node" - I mean that after getting collected statistics
client node can cache server node which has sent statistics to get future
updates. Client will renew its cache with TTL approach while server can
decide when statistics should be collected again by, for example, counting
the number of changed rows in underlying tables.
"Whats the storage mechanism for client node statistics?" - no storage,
even server node won't store global statistics persistently, but they will
store local partition level statistics to speedup collection (do
aggregation instead of collection) after restart.
"Can we use thin client without discs in such cases?" - certainly, no
persistent store needed on any client nodes.
I made minor changes in IEP according to your notices. Follow-up questions
are welcome.

пт, 16 окт. 2020 г. в 14:31, Zhenya Stanilovsky :

>
> Andrey, thanks for firing this !
> Sasha it`s unclear for me « These part consists of two processes:
> statistics collection process itself and acquiring statistics by the
> client. »:
> *  I agree that in both cases local statistics are useless.
> May be we need more informative use cases for such statistics usage ? Can
> someone append additional columns (possible not presented in index)
> statistics?
> *  Client — can you unfold this term ?  If this means — ignite client node
> ? Does sql best plan is chosen in request starter node ? If so — what about
> this client with limited cpu here?
> *  « If there are no statistics in all of them - client will choose random
>   » — not random but affinity concerted isn`t it ?
> *  « After getting statistics client will cache it and server node it to
> renew statistics from same node. ​​​»  I don`t understand this
> approach, can you clarify it plz ?
> *  Whats the storage mechanism for client node statistics?
> *  Can we use thin client without discs in such cases?
> thanks !
>
> >:
> >
> >Follow up
> >
> >Igniters,
> >
> >is there any comment to this IEP?
> >
> >JFYI, IEP is renamed and placed here [1]
> >
> >[1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-58%3A+Statistics+for+SQL+query+optimization
> >
> >On Thu, Sep 24, 2020 at 2:30 PM Sasha Belyak < rtsfo...@gmail.com >
> wrote:
> >>
> >> Igniters,
> >> I'e prepared an IEP [1], please review and let me know what you think.
> >>
> >> In particular, I'd like to discuss the new subsystem to collect
> statistics
> >> to optimize sql queries execution.
> >> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-58+Statistics
>
>
>

IEP-58: Statistics

[Sasha Belyak]

Igniters,
I'e prepared an IEP [1], please review and let me know what you think.

In particular, I'd like to discuss the new subsystem to collect statistics
to optimize sql queries execution.
[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-58+Statistics

Re: Cluster name

[Sasha Belyak]

Cluster name - yes
Limit cluster building by cluster name - yes
env/system property - no, let's add cluster name to ignite configuration.

2017-10-11 17:08 GMT+07:00 Dmitry Pavlov :

> I like this idea too. Some imdg have such feature and allow to limit
> cluster building only within cluster name.
>
> ср, 11 окт. 2017 г. в 12:38, Alexey Kuznetsov :
>
> > Hi,
> >
> > I'd like to up this thread for discussion.
> >
> > It seems that cluster name could be very useful together with multicast
> > discovery - do not accept nodes with different cluster name.
> > By default, let's set cluster name to "DEFAULT_CLUSTER".
> >
> > Thoughts?
> >
> > On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I am not sure I like naming clusters from an agent. It just sounds
> > counter
> > > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> > > property together with optional  -DCLUSTER_NAME system property and
> > > reserved CLUSTER_NAME user attribute?
> > >
> > > If user fails to provide any of the above, then we automatically assign
> > the
> > > timestamp of the first node or some UUID as a cluster name.
> > >
> > > Thoughts?
> > >
> > > D.
> > >
> > > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > >
> > > > Cluster doesn't know about the console, but web agent does, right? I
> > > think
> > > > it should be his responsibility to assign the name. I.e. when
> starting
> > > the
> > > > agent next to a particular cluster, user has to specify the name. If
> > the
> > > > console already has the cluster with this name, agent should not
> start
> > > with
> > > > an exception suggesting to provide another name.
> > > >
> > > > Will this work?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > > akuznet...@apache.org>
> > > > wrote:
> > > >
> > > > > Dmitriy, Sergi and Val.
> > > > >
> > > > > Web Console will be connected to several clusters at once.
> > > > > And clusters do not know about Web Console, because Web Console
> > collect
> > > > > info from cluster via our REST-HTTP module.
> > > > > So, I can distinguish clusters only by collection of node IDs and
> > give
> > > > them
> > > > > names like: "Cluster1, Clsuter2,"
> > > > > But if cluster restarted Web Console will detect it as new cluster
> > and
> > > > give
> > > > > next auto-generated name "ClusterN".
> > > > >
> > > > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration,
> > but
> > > > > could you give me a way
> > > > >  some how "mark" clusters to detect them even after full restart.
> > > > >
> > > > > May be setting some sort of environment variable (it will be added
> to
> > > > node
> > > > > attributes)?
> > > > > So, if user need "Multi-cluster" support he should set different
> > > > > CLUSTER_NAME environment variable for different clusters.
> > > > >
> > > > > Any other ideas are welcome.
> > > > >
> > > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > How does the workflow look like? How do you add a cluster to this
> > > > > dropdown
> > > > > > on the console? I think that assigning a name should be part of
> > this
> > > > > > process and should happen on the console itself.
> > > > > >
> > > > > > Adding yet another "name" to configuration will only confuse
> users
> > > even
> > > > > > more.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I don't like to add anything like this into Ignite config. It
> is
> > a
> > > > > > problem
> > > > > > > of Web console how to name or rename different clusters for a
> > user,
> > > > but
> > > > > > not
> > > > > > > Ignite cluster itself.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > > > >
> > > > > > > > I am OK with having a cluster name, but I would like us to
> > > generate
> > > > > one
> > > > > > > > automatically, if users do not define one explicitly. How
> about
> > > > > > > > "cluster_timestamp"?
> > > > > > > >
> > > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > > akuznet...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I'm planning to start working on multi cluster support for
> > Web
> > > > > > Console
> > > > > > > > > in order to be able to execute SQL queries on different
> > > clusters
> > > > > just
> > > > > > > by
> > > > > > > > > selecting
> > > > > > > > > target cluster from drop-down.
> > > > > > > > >
> > > > > > > > > But Ignite does not have any cluster 

Re: Monitoring of active transactions

[Sasha Belyak]

On Thu, Oct 5, 2017 at 1:24 PM, Alexey Goncharuk <alexey.goncha...@gmail.com
> wrote:

> Guys,
>
> I think we should not limit this functionality to http-rest only. We
should
> add this information to one of the MBeans as the primary information
> source. Then this should be added as a client command both to http-rest
and
> binary-rest endpoints, so the information is available through different
> tools.
>
> Thoughts?
Agree. Should we discuss command parameters here? For now txViewer handle 2
options:
1) time to decide that tx is "long", int in ms
2) server only flag to filter only tx's started from server, bool
I suggest it should handle:
1) time, int in ms
2) nodeType= {server,client,all}, all is default
3) show tx only or tx with keys, keys+values: entries={no,keys,entries} no
is default
maybe some filters, like:
4) nodes= to select tx only from specified nodes
5) txId= to select entries only by specified tx
6) cache= to select only tx with entries in specified cache(s?)
7) some another filter options like tx isolation level/tx mode, can anybody
write use cases for it?

2017-10-05 21:24 GMT+07:00 Ilya Lantukh <ilant...@gridgain.com>:

> On Thu, Oct 5, 2017 at 1:24 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > Guys,
> >
> > I think we should not limit this functionality to http-rest only. We
> should
> > add this information to one of the MBeans as the primary information
> > source. Then this should be added as a client command both to http-rest
> and
> > binary-rest endpoints, so the information is available through different
> > tools.
> >
> > Thoughts?
>
> I agree with this approach.
>
> On Thu, Oct 5, 2017 at 1:24 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > Guys,
> >
> > I think we should not limit this functionality to http-rest only. We
> should
> > add this information to one of the MBeans as the primary information
> > source. Then this should be added as a client command both to http-rest
> and
> > binary-rest endpoints, so the information is available through different
> > tools.
> >
> > Thoughts?
> >
> > 2017-09-28 13:35 GMT+03:00 Sasha Belyak <rtsfo...@gmail.com>:
> >
> > > It's very useful, but I often we need to get list of hang transaction
> > when
> > > exchange stopped by some reason and in this case utility, based on
> client
> > > node won't help. I rewrite it as ComputeTask with default constructor,
> > add
> > > jar into ignite libs, activate http rest api and now it can be used
> from
> > > console and no need to update cluster topology:
> > >
> > > curl '
> > > http://127.0.0.1:8080/ignite?cmd=exe=org.apache.ignite.txviewer.
> > > RestCollectTxInfoTask=false=100
> > > '
> > >
> > > {"successStatus":0,"sessionToken":null,"error":
> null,"response":{"id":"~
> > > 98391a83-3d76-4e5e-b0c3-185cf2bd4acd","finished":true,
> > > "error":null,"result":[{"nearXidVersion":"GridCacheVersion
> > > [topVer=118063514, order=1506583525449,
> > > nodeOrder=2]","nodeId":"baa0237e-707c-4b69-abb6-
> > > 555a2fc17762","nodeString":"TcpDiscoveryNode
> > > [id=baa0237e-707c-4b69-abb6-555a2fc17762, addrs=[0:0:0:0:0:0:0:1%1,
> > > 10.0.3.1, 10.38.176.253, 10.42.1.107, 127.0.0.1, 172.17.0.1],
> > sockAddrs=[/
> > > 127.0.0.1:0, /10.42.1.107:0, /0:0:0:0:0:0:0:1%1:0, /172.17.0.1:0, /
> > > 10.38.176.253:0, /10.0.3.1:0], discPort=0, order=2, intOrder=0,
> > > lastExchangeTime=1506583525683, loc=true, ver=2.1.5#20170922-sha1:
> > > 6452201d,
> > > isClient=true]","threadId":1,"startTime":"Thu Sep 28 14:25:27 NOVT
> > > 2017","entries":[{"cache":"txCache","key":"1","value":"1"
> > > ,"operation":"CREATE"}]}]}}
> > >
> > > Even better if this tool can use binary rest too. I mean that we should
> > be
> > > able to run this collecting task from:
> > > 1) http rest api by curl/wget (but must deploy class somehow before, by
> > > peerClassLoad with Continues mode or by adding it to application
> > classpash)
> > > Good for admin's console scripting.
> > > 2) binary rest api by some java tool (with instant peerClassLoading).
> > Good
> > > for investigation on any grid configuration.
> > > 3) maybe, by cli

Re: Monitoring of active transactions

[Sasha Belyak]

It's very useful, but I often we need to get list of hang transaction when
exchange stopped by some reason and in this case utility, based on client
node won't help. I rewrite it as ComputeTask with default constructor, add
jar into ignite libs, activate http rest api and now it can be used from
console and no need to update cluster topology:

curl '
http://127.0.0.1:8080/ignite?cmd=exe=org.apache.ignite.txviewer.RestCollectTxInfoTask=false=100
'

{"successStatus":0,"sessionToken":null,"error":null,"response":{"id":"~98391a83-3d76-4e5e-b0c3-185cf2bd4acd","finished":true,"error":null,"result":[{"nearXidVersion":"GridCacheVersion
[topVer=118063514, order=1506583525449,
nodeOrder=2]","nodeId":"baa0237e-707c-4b69-abb6-555a2fc17762","nodeString":"TcpDiscoveryNode
[id=baa0237e-707c-4b69-abb6-555a2fc17762, addrs=[0:0:0:0:0:0:0:1%1,
10.0.3.1, 10.38.176.253, 10.42.1.107, 127.0.0.1, 172.17.0.1], sockAddrs=[/
127.0.0.1:0, /10.42.1.107:0, /0:0:0:0:0:0:0:1%1:0, /172.17.0.1:0, /
10.38.176.253:0, /10.0.3.1:0], discPort=0, order=2, intOrder=0,
lastExchangeTime=1506583525683, loc=true, ver=2.1.5#20170922-sha1:6452201d,
isClient=true]","threadId":1,"startTime":"Thu Sep 28 14:25:27 NOVT
2017","entries":[{"cache":"txCache","key":"1","value":"1","operation":"CREATE"}]}]}}

Even better if this tool can use binary rest too. I mean that we should be
able to run this collecting task from:
1) http rest api by curl/wget (but must deploy class somehow before, by
peerClassLoad with Continues mode or by adding it to application classpash)
Good for admin's console scripting.
2) binary rest api by some java tool (with instant peerClassLoading). Good
for investigation on any grid configuration.
3) maybe, by client node as it implemented now (can't see any adwantages)


2017-09-16 5:35 GMT+07:00 Dmitry Pavlov :

> Hi Ilya,
>
> I can help with including this utility into build/release, I've recenty
> finished same steps for PDS WAL analysing tool for converting records to
> human readable format.
> Please feel free to contact me.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 15 сент. 2017 г. в 6:37, Dmitriy Setrakyan :
>
> > It seems that the community (including me) really would like to see this
> > feature in Ignite.
> >
> > Ilya, can you create a ticket and submit it for review?
> >
> > D.
> >
> > On Fri, Sep 8, 2017 at 7:15 AM, Anton Vinogradov  wrote:
> >
> > > Ilya,
> > >
> > > We extremely need this!
> > >
> > > Txs and Locks info should be collected on each cluster hang.
> > > We already have an issue related to this problem -
> > > https://issues.apache.org/jira/browse/IGNITE-4937
> > >
> > > Nikolay,
> > >
> > > Good point,
> > > but, seems you should start separate thread to discuss this.
> > >
> > > On Fri, Sep 8, 2017 at 4:28 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > Hi Ilya,
> > > >
> > > > I'm definitely +1 for including the utility in the product. Perfect
> > > > contribution.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 8 сент. 2017 г. в 14:28, Ilya Lantukh :
> > > >
> > > > > Igniters,
> > > > >
> > > > > According to our current design and implementation, unclosed
> > > transaction
> > > > or
> > > > > unreleased lock can hang ignite cluster forever. This is logical,
> and
> > > > with
> > > > > correct usage of those mechanics such issue should never happen, in
> > > real
> > > > > world developers can make mistakes and leave transaction open. We
> > have
> > > a
> > > > > feature "transaction timeout", but turns out it doesn't work in all
> > > cases
> > > > > (see https://issues.apache.org/jira/browse/IGNITE-6181). Even if
> all
> > > > known
> > > > > issues are fixed, there is still a lot of room for mistake and
> > > incorrect
> > > > > usage.
> > > > >
> > > > > To make it possible for Ignite users to discover such problem and
> > trace
> > > > it
> > > > > to a particular part of code, I've created a very simple utility
> that
> > > > > collects and prints information about long running transactions for
> > the
> > > > > whole cluster. It is available here:
> > > > > https://github.com/ilantukh/IgniteTxViewer.
> > > > >
> > > > > One might expect such monitoring utilities to be included in Ignite
> > > > > codebase. Personally, I think that such information should be
> > available
> > > > > from public API, without using of additional applications or diving
> > > into
> > > > > Ignite internals.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ilya
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Sasha Belyak]

+1

2017-07-21 5:34 GMT+07:00 Denis Magda :

> Igniters,
>
> Setting off the vote one more time. Hope I’ll be successful this time,
> keeping fingers crossed :)
>
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
>
> Git tag name is
> 2.1.0-rc3
>
> This release includes the following changes:
>
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
>
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
>
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
>
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%
> 20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.1.0-rc3
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
>
> This vote will go for 72 hours.
>
> —
> Denis
>
>

HttpRest API with active/inactive/currentState commands

[Sasha Belyak]

Hi,
I'v made small branch with new http rest api commands to activate,
deactivate and check current state of cluster.
review link: http://reviews.ignite.apache.org/ignite/review/IGNT-CR-234
apache issue link: https://issues.apache.org/jira/browse/IGNITE-5733
can anyone review this?
Best regards,
Alexander.

Add ability to enable and disable rebalancing per-node

[Sasha Belyak]

Hi,
I have jira ticket https://issues.apache.org/jira/browse/IGNITE-5061 with
subj and now I'm trying to understand partition exchange mechanism.
As far as I understand, task point is: it need when we have to grow cluster
(start few new nodes without partition exchange and enable exchange after
we completely get desired topology).
All nodes know actual partition topology, so partitions can stay unbalanced
for long time.
How I see solution:
1) Add in ignite MBean some flag enablePartitionExchange
2) Test it in GridDhtPartitionDemander.requestPartitions and complete
RebalanceFuture if partitionExchange is disabled
3) Somehow fire up force rebalance when flag change to true.
Does anybody see problems with this solution? Maybe we need to add
per-cache granularity or let system caches rebalance even if
enablePartitionExchange=false? Does we have some huge changes in progress,
which can conflict with it?

Using long for configure network timeouts

[Sasha Belyak]

Now in ignite configurations in many network related parameters (for
example: IgniteConfiguration.netTimeout, TcpDiscoverySpi.socketTimeout,
TcpDiscoverySpi.ackTimeout) used long. But network socket using int for
socket timeout, so we do simple "(int)timeout" type casting and if timeout
value > Integer.MAX_VALUE - get exception.
The question is: why we use long type?

IGNITE-4799 MetricsUpdate after each job

[Sasha Belyak]

Now IgniteConfiguration.MetricsUpdate now can be:
-1 - disabled
0 - collect after each job
>0 - collect after specified amount in ms.
If we will use this parameter to send metrics - we should remove this
options and leave only >0 values available. Should I remove any 0 and -1
mentions in 4799?

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Sasha Belyak]

Yakov, I can do replacement "heartbeat" -> "metricsUpdate". Can I get
https://issues.apache.org/jira/browse/IGNITE-4799 ?

2017-04-10 14:50 GMT+03:00 Yakov Zhdanov :

> Guys, I have finished with initial changes. There were a little bit more
> work to do than I originally estimated.
>
> Denis, can you please reply in the ticket? I would like you to propose
> documentation changes. Can you help?
>
> There is also another question - we have a lot of "heartbeat" mentions in
> TCP disco - missed heartbeats, client heartbeats, heartbeat message. Should
> we go ahead and refactor this as well e.g. to maxMissedMetricUpdates?
>
> Also there are some changes to platforms and webconsole required. Alex
> Kuznetsov and Pavel Tupitsyn can you take a look at respective parts?
>
> --
> Yakov
>

Hello Ignite

[Sasha Belyak]

Hello Ignite Community!

My name is Alexander. I want to contribute to Apache Ignite and want to
start with this issue - IGNITE-4927. Any help on this will be appreciated.
Can anyone give me an access to Apache Ignite JIRA? My username is sbberkov.

Thanks!

Re: Hello everyone

[Sasha Belyak]

My username at issues.apache.org Jira is Berkov.

2016-09-13 21:57 GMT+07:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Hi Alexander,
>
> Welcome!
>
> Please let us know your JIRA username and we will add you to the
> contributor list. Also go through page [1] for all the information about
> the development process.
>
> [1] http://ignite.apache.org/community/contribute.html#contribute
>
> -Val
>
> On Tue, Sep 13, 2016 at 7:03 AM, Sasha Belyak <rtsfo...@gmail.com> wrote:
>
> > Hello Ignite community!
> > My name is Alexander and I want to contribute to Apache Ignite. I want to
> > start with this issue - IGNITE-1075.
> > This project seems to be interesting for me, because I love projects with
> > server side processing tasks/api development and so on.
> > Thanks.
> >
>

Hello everyone

[Sasha Belyak]

Hello Ignite community!
My name is Alexander and I want to contribute to Apache Ignite. I want to
start with this issue - IGNITE-1075.
This project seems to be interesting for me, because I love projects with
server side processing tasks/api development and so on.
Thanks.