Re: Update ignite version for Camel, Zeppelin, Vert.x and MyBatis

[Roman Shtykh]

MyBatis integration is in maven repository now.Btw, the links at [1] are old 
(pointing to apacheignite.readme.io instead of apacheignite-mix.readme.io).
Roman
 

On Wednesday, December 14, 2016 11:04 AM, Roman Shtykh 
 wrote:
 

 Denis,

Sure, I will update MyBatis.

-Roman



On Wednesday, December 14, 2016 5:42 AM, Denis Magda  wrote:
Raul K., Andrey G., Roman S.,

Would you mind updating pom files of the external projects [1] Ignite is 
integrated with by setting its version to 1.8.0?

https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations 


—
Denis 

   

Re: Update ignite version for Camel, Zeppelin, Vert.x and MyBatis

[Roman Shtykh]

Denis,

Sure, I will update MyBatis.

-Roman



On Wednesday, December 14, 2016 5:42 AM, Denis Magda  wrote:
Raul K., Andrey G., Roman S.,

Would you mind updating pom files of the external projects [1] Ignite is 
integrated with by setting its version to 1.8.0?

https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations 


—
Denis 

Re: affinityCall in one distributed transaction

[Dmitriy Setrakyan]

On Tue, Dec 13, 2016 at 11:22 AM, Игорь Г  wrote:

> Dmitriy, for p.1 we can enroll it in one JTA transaction, yes.
> But is there a cheaper way to do it?


We have to pick whether we use JTA for this use case at all. If yes, then
it should be used across the whole system and no additional development is
required. If we do not use JTA, then we need to come up with proper API to
support it.


> I think in p.2 Anton means that if we
> can start ignite transaction on one client node and "join" it on other
> client node (by some id) so that all changes made on 2nd client were inside
> this transaction it will work much faster.
>

This is only valid if we decide not to use JTA. Can you please suggest an
API here?


>
>
>
>
> 2016-12-13 12:31 GMT+03:00 Dmitriy Setrakyan :
>
> > On Tue, Dec 13, 2016 at 1:29 AM, Антон Чураев 
> > wrote:
> >
> > > Using JTA in current implementation Ignite is possible. But it is
> > > expensive, because currently Ignite does not support distributed
> > > transaction context within all grid.
> > >
> > > I think it would be right to devide task into two:
> > > 1) Add support of switching transactional context between multiple
> thread
> > > within single instance jvm;
> > >
> >
> > Can you please suggest an API for it?
> >
> >
> > > 2) Using distributed memory for keeping transaction context;
> > >
> >
> > What do you mean by distributed memory here?
> >
> >
> > >
> > > In my opinion, the first one is not so difficult to implement.
> > >
> > > 2016-12-13 1:29 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Anton,
> > > >
> > > > Looking at this sequence, I don't see any way of achieving it other
> > than
> > > > enrolling all transactions into one JTA transaction. If you seen
> > another
> > > > way, can you please suggest it here?
> > > >
> > > > D.
> > > >
> > > > On Sat, Dec 10, 2016 at 2:07 PM, Антон Чураев 
> > > > wrote:
> > > >
> > > > > Dmitriy, it's ok
> > > > >
> > > > > To be abstract simple business transaction for execution payment
> > > > > (preparation done before)  from the card looks like:
> > > > > 1) Create a payment document (cache API);
> > > > > 2) Write-off funds from the payer's card;
> > > > > 2.1) Change in register #1 (cache API);
> > > > > 2.2) Change in register #2 (cache API);
> > > > > 2.3) Change in register #... (cache API);
> > > > > 2.4) Change limits of card (cache API);
> > > > > 3) Payment to service provider;
> > > > > 3.1) Change in the balance of business unit having the contract
> with
> > > > payer
> > > > > (cache API);
> > > > > 3.2) Change in the balance of business unit having the contract
> with
> > > > > provider (cache API);
> > > > > 3.3) Change in the balance of the account (cache API);
> > > > > 3.4.1) Some change in registers... (cache API);
> > > > > 3.4.2) ...;
> > > > > 3.3) ...
> > > > > 3.4) Invoke provider's API for billing payment of payer;
> > > > > 4) Formation of financial statements (it's possible to implement
> > > > off-line -
> > > > > in other transational)
> > > > > 4.1) ...
> > > > > 4.2) ...
> > > > >
> > > > > And all steps have been designed into separate microservices. And,
> of
> > > > > course, it have been designed via asynchronous transport.
> > > > > On the other hand it seems to be that implementation of
> coordination
> > of
> > > > > 10-20 local transactions is not a good idea
> > > > >
> > > > > 2016-12-10 23:30 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Anton,
> > > > > >
> > > > > > Thanks for the explanation. I am sorry to keep asking questions
> on
> > > > this.
> > > > > > Can you change your example to include concrete Ignite calls on
> > > Compute
> > > > > or
> > > > > > Cache APIs (or other APIs)? I am still struggling to understand
> the
> > > > > > boundaries between business and Ignite logic.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Sat, Dec 10, 2016 at 5:46 AM, Антон Чураев <
> > churaev...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > For example:
> > > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > > 2) Some application (like a business transactional coordinator)
> > > > > receives
> > > > > > > message via asynchronous transport. This application implements
> > > logic
> > > > > of
> > > > > > > calling different services sequentially or in parallel via
> > > > asynchronous
> > > > > > > transport.
> > > > > > > 3) Each service implement some little changes in a cache.
> > > > > > >
> > > > > > > Or:
> > > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > > 2) This transaction is implemented in microservice architecture
> > > > (large
> > > > > > > number microservices + asynchronous transport).
> > > > > > > 3) Each microservice implement some little changes in a cache.
> > > > > > >
> > > > > > > I think it is possible to implement distributed 

FWD: Hibernate OGM and Ignite (beginning of the story)

[Denis Magda]

Shamim, great thanks!

Copying our conversion to Ignite’s dev and user lists.

Igniters, Shamim posted a useful blog post about the usage of Hibernate OGM and 
Ignite integration.  
https://dzone.com/articles/apache-ignite-with-jpa-a-missing-element 


I hope this integration will be merged soon into Hibernate repository but you 
already can give it a try in practice.

Prachi, could you add this blog post to our blogs list? Shamim, if you don’t 
mind we will use this picture of you.
https://dzone.com/users/284671/shamim_ru.html 



—
Denis

> On Dec 13, 2016, at 2:54 AM, sre...@yandex.ru wrote:
> 
> Denis, thank's for your interest to add this article to Apache Ignite blog. 
> Yes, you can add this it to Ignite blog (actually, i do not know, where to 
> add it properly).
> 
> Best regards
> 
>  Shamim Ahmed 
> 
> _
> Sent from http://apache-ignite-users.70518.x6.nabble.com
> 

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Denis Magda]

Maven Central should grab the changes during the next update window. The ticket 
is left opened until this happens. However, the issue was fixed in general, the 
artifacts are accessible from the pom file.

—
Denis

> On Dec 13, 2016, at 4:21 PM, Dmitriy Setrakyan  wrote:
> 
> I still don't see version 1.8 here:
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-core
> 
> D.
> 
> On Tue, Dec 13, 2016 at 12:16 PM, Denis Magda  wrote:
> 
>> Finally, the issue has been resolved
>> https://issues.apache.org/jira/browse/INFRA-13073 <
>> https://issues.apache.org/jira/browse/INFRA-13073>
>> 
>> I could run examples using 1.8.0 artifacts. Going to send an announcement
>> shortly.
>> 
>> —
>> Denis
>> 
>>> On Dec 13, 2016, at 1:32 AM, Anton Vinogradov 
>> wrote:
>>> 
>>> Pgp signature seems to be correct, signed by sboikov.
>>> 
>>> Seems, that sonatype reason equals to http://repo.maven.apache.org/
>> maven2
>>> reason.
>>> 
>>> I've reasked infra to check logs.
>>> 
>>> On Tue, Dec 13, 2016 at 11:25 AM, Sergey Kozlov 
>>> wrote:
>>> 
 Geospatial and some other modules have been removed purposely.
 
 The key change between 1.7.0 and 1.8.0 for maven deployment is splitting
 cassandra module into two separate modules: cassandra-store and
 cassandra-serializers.
 
 On Tue, Dec 13, 2016 at 3:27 AM, Denis Magda  wrote:
 
> 
>> On Dec 12, 2016, at 4:08 PM, Konstantin Boudnik 
 wrote:
>> 
>> Interestingly enough, looking thought the artifacts in Maven, I see
>> a whole bunch of the component that are pulled from the latest
>> releases
> yet
>> are presented in the Maven. Say geospacial is only published up to
> 1.2.0, etc.
> 
> It looks weird to me as well. Could you start a separate discussion on
 the
> dev list in order to trigger attention of the guys who usually take
>> care
> about Ignite’s build system?
> 
> —
> Denis
 
 
 
 
 --
 Sergey Kozlov
 GridGain Systems
 www.gridgain.com
 
>> 
>> 

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Dmitriy Setrakyan]

I still don't see version 1.8 here:
https://mvnrepository.com/artifact/org.apache.ignite/ignite-core

D.

On Tue, Dec 13, 2016 at 12:16 PM, Denis Magda  wrote:

> Finally, the issue has been resolved
> https://issues.apache.org/jira/browse/INFRA-13073 <
> https://issues.apache.org/jira/browse/INFRA-13073>
>
> I could run examples using 1.8.0 artifacts. Going to send an announcement
> shortly.
>
> —
> Denis
>
> > On Dec 13, 2016, at 1:32 AM, Anton Vinogradov 
> wrote:
> >
> > Pgp signature seems to be correct, signed by sboikov.
> >
> > Seems, that sonatype reason equals to http://repo.maven.apache.org/
> maven2
> > reason.
> >
> > I've reasked infra to check logs.
> >
> > On Tue, Dec 13, 2016 at 11:25 AM, Sergey Kozlov 
> > wrote:
> >
> >> Geospatial and some other modules have been removed purposely.
> >>
> >> The key change between 1.7.0 and 1.8.0 for maven deployment is splitting
> >> cassandra module into two separate modules: cassandra-store and
> >> cassandra-serializers.
> >>
> >> On Tue, Dec 13, 2016 at 3:27 AM, Denis Magda  wrote:
> >>
> >>>
>  On Dec 12, 2016, at 4:08 PM, Konstantin Boudnik 
> >> wrote:
> 
>  Interestingly enough, looking thought the artifacts in Maven, I see
>  a whole bunch of the component that are pulled from the latest
> releases
> >>> yet
>  are presented in the Maven. Say geospacial is only published up to
> >>> 1.2.0, etc.
> >>>
> >>> It looks weird to me as well. Could you start a separate discussion on
> >> the
> >>> dev list in order to trigger attention of the guys who usually take
> care
> >>> about Ignite’s build system?
> >>>
> >>> —
> >>> Denis
> >>
> >>
> >>
> >>
> >> --
> >> Sergey Kozlov
> >> GridGain Systems
> >> www.gridgain.com
> >>
>
>

Update ignite version for Camel, Zeppelin, Vert.x and MyBatis

[Denis Magda]

Raul K., Andrey G., Roman S.,

Would you mind updating pom files of the external projects [1] Ignite is 
integrated with by setting its version to 1.8.0?

https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations 


—
Denis

[ANNOUNCE] Apache Ignite 1.8.0 Released

[Denis Magda]

The Apache Ignite Community is pleased to announce the release of Apache Ignite 
1.8.0.

Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
distributed in-memory platform for computing and transacting on large-scale 
data sets in real-time, orders of magnitude faster than possible with 
traditional disk-based or flash-based technologies.

The Fabric is a collection of independent and well integrated components some 
of which are the following:  
Data Grid
Compute Grid
Streaming & CEP
Service Grid

Starting from version 1.8.0 this list is expanded with a new component named 
In-Memory SQL Grid [2]. In-Memory SQL Grid adds in-memory distributed database 
capabilities to Apache Ignite. It is horizontally scalable, fault tolerant and 
SQL ANSI-99 compliant. SQL Grid fully supports all SQL and DML commands 
including SELECT, UPDATE, INSERT, MERGE and DELETE queries. The In-Memory SQL 
Grid allows you to interact with Ignite platform using JDBC or ODBC APIs 
without custom coding. This provides true cross-platform connectivity even from 
languages such as PHP and Ruby which are not natively supported by the project. 
 
Apache Ignite 1.8.0 also includes Redis protocol support and support for .NET 
Entity Framework 2nd Level Cache and ASP.NET Session Caching. The full list of 
the changes can be found here [3].

Please visit this page if you’re ready to try the release out:
https://ignite.apache.org/download.cgi 

Please let us know [4] if you encounter any problems.

Regards,

The Apache Ignite Community

[1] https://ignite.apache.org 
[2] https://apacheignite.readme.io/docs/sql-grid 

[3] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
[4] https://ignite.apache.org/community/resources.html#ask 

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Denis Magda]

Finally, the issue has been resolved
https://issues.apache.org/jira/browse/INFRA-13073 


I could run examples using 1.8.0 artifacts. Going to send an announcement 
shortly.

—
Denis

> On Dec 13, 2016, at 1:32 AM, Anton Vinogradov  
> wrote:
> 
> Pgp signature seems to be correct, signed by sboikov.
> 
> Seems, that sonatype reason equals to http://repo.maven.apache.org/maven2
> reason.
> 
> I've reasked infra to check logs.
> 
> On Tue, Dec 13, 2016 at 11:25 AM, Sergey Kozlov 
> wrote:
> 
>> Geospatial and some other modules have been removed purposely.
>> 
>> The key change between 1.7.0 and 1.8.0 for maven deployment is splitting
>> cassandra module into two separate modules: cassandra-store and
>> cassandra-serializers.
>> 
>> On Tue, Dec 13, 2016 at 3:27 AM, Denis Magda  wrote:
>> 
>>> 
 On Dec 12, 2016, at 4:08 PM, Konstantin Boudnik 
>> wrote:
 
 Interestingly enough, looking thought the artifacts in Maven, I see
 a whole bunch of the component that are pulled from the latest releases
>>> yet
 are presented in the Maven. Say geospacial is only published up to
>>> 1.2.0, etc.
>>> 
>>> It looks weird to me as well. Could you start a separate discussion on
>> the
>>> dev list in order to trigger attention of the guys who usually take care
>>> about Ignite’s build system?
>>> 
>>> —
>>> Denis
>> 
>> 
>> 
>> 
>> --
>> Sergey Kozlov
>> GridGain Systems
>> www.gridgain.com
>> 

Re: affinityCall in one distributed transaction

[Игорь Г]

Dmitriy, for p.1 we can enroll it in one JTA transaction, yes.
But is there a cheaper way to do it? I think in p.2 Anton means that if we
can start ignite transaction on one client node and "join" it on other
client node (by some id) so that all changes made on 2nd client were inside
this transaction it will work much faster.




2016-12-13 12:31 GMT+03:00 Dmitriy Setrakyan :

> On Tue, Dec 13, 2016 at 1:29 AM, Антон Чураев 
> wrote:
>
> > Using JTA in current implementation Ignite is possible. But it is
> > expensive, because currently Ignite does not support distributed
> > transaction context within all grid.
> >
> > I think it would be right to devide task into two:
> > 1) Add support of switching transactional context between multiple thread
> > within single instance jvm;
> >
>
> Can you please suggest an API for it?
>
>
> > 2) Using distributed memory for keeping transaction context;
> >
>
> What do you mean by distributed memory here?
>
>
> >
> > In my opinion, the first one is not so difficult to implement.
> >
> > 2016-12-13 1:29 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Anton,
> > >
> > > Looking at this sequence, I don't see any way of achieving it other
> than
> > > enrolling all transactions into one JTA transaction. If you seen
> another
> > > way, can you please suggest it here?
> > >
> > > D.
> > >
> > > On Sat, Dec 10, 2016 at 2:07 PM, Антон Чураев 
> > > wrote:
> > >
> > > > Dmitriy, it's ok
> > > >
> > > > To be abstract simple business transaction for execution payment
> > > > (preparation done before)  from the card looks like:
> > > > 1) Create a payment document (cache API);
> > > > 2) Write-off funds from the payer's card;
> > > > 2.1) Change in register #1 (cache API);
> > > > 2.2) Change in register #2 (cache API);
> > > > 2.3) Change in register #... (cache API);
> > > > 2.4) Change limits of card (cache API);
> > > > 3) Payment to service provider;
> > > > 3.1) Change in the balance of business unit having the contract with
> > > payer
> > > > (cache API);
> > > > 3.2) Change in the balance of business unit having the contract with
> > > > provider (cache API);
> > > > 3.3) Change in the balance of the account (cache API);
> > > > 3.4.1) Some change in registers... (cache API);
> > > > 3.4.2) ...;
> > > > 3.3) ...
> > > > 3.4) Invoke provider's API for billing payment of payer;
> > > > 4) Formation of financial statements (it's possible to implement
> > > off-line -
> > > > in other transational)
> > > > 4.1) ...
> > > > 4.2) ...
> > > >
> > > > And all steps have been designed into separate microservices. And, of
> > > > course, it have been designed via asynchronous transport.
> > > > On the other hand it seems to be that implementation of coordination
> of
> > > > 10-20 local transactions is not a good idea
> > > >
> > > > 2016-12-10 23:30 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > Anton,
> > > > >
> > > > > Thanks for the explanation. I am sorry to keep asking questions on
> > > this.
> > > > > Can you change your example to include concrete Ignite calls on
> > Compute
> > > > or
> > > > > Cache APIs (or other APIs)? I am still struggling to understand the
> > > > > boundaries between business and Ignite logic.
> > > > >
> > > > > D.
> > > > >
> > > > > On Sat, Dec 10, 2016 at 5:46 AM, Антон Чураев <
> churaev...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > For example:
> > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > 2) Some application (like a business transactional coordinator)
> > > > receives
> > > > > > message via asynchronous transport. This application implements
> > logic
> > > > of
> > > > > > calling different services sequentially or in parallel via
> > > asynchronous
> > > > > > transport.
> > > > > > 3) Each service implement some little changes in a cache.
> > > > > >
> > > > > > Or:
> > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > 2) This transaction is implemented in microservice architecture
> > > (large
> > > > > > number microservices + asynchronous transport).
> > > > > > 3) Each microservice implement some little changes in a cache.
> > > > > >
> > > > > > I think it is possible to implement distributed transactional
> using
> > > XA
> > > > > > coordinator outside Ignite and local transaction in each service.
> > But
> > > > its
> > > > > > cost may be unacceptable especially in the case of using a large
> > > number
> > > > > of
> > > > > > services.
> > > > > >
> > > > > > I think distributed transaction inside Ignite could be useful
> also
> > > for
> > > > > > using multiple ComputeTask in one transaction.
> > > > > >
> > > > > > 2016-12-09 21:45 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > > >
> > > > > > > Sounds like you need a centralized JTA server for this type of
> > > > purpose,
> > > > > > no?
> > > > > > > In 

[GitHub] ignite pull request #1342: IGNITE-4421: Added BinaryObject handling in ODBC.

[isapego]

GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/1342

IGNITE-4421: Added BinaryObject handling in ODBC.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4421

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1342.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1342


commit 3df412e7f25aac8227b68cffe1577593a05d1431
Author: sboikov 
Date:   2016-12-07T09:25:32Z

ignite-2545 Optimization for GridCompoundFuture's futures iteration

commit f3db74f782c68c7f73ef3ef4390e010976493634
Author: Anton Vinogradov 
Date:   2016-12-07T10:15:37Z

IGNITE-4238: Added geospatial queries example (nolgpl examples hotfix)

commit 56efb10c40fd4481d6a9dc00928e7beee1f164c5
Author: Anton Vinogradov 
Date:   2016-12-07T11:25:53Z

IGNITE-4353 Parent Cassandra module deployed on maven repository (hotfix: 
deploy to custom maven repository)

commit 83710a9d1bb7379e5f3d891ed95c86096263740b
Author: Pavel Tupitsyn 
Date:   2016-12-12T14:52:22Z

IGNITE-4413 .NET: Fix DateTime argument handling in SqlQuery

This closes #1341

commit 5d8b6b8e9fab87b36b9a58db18b8bed2e0796d05
Author: Igor Sapego 
Date:   2016-12-13T13:59:14Z

IGNITE-4421: Added BinaryObject handling in ODBC.

commit 2d44a33055919d8da914b0b12c1a4d05b7ba9c58
Author: Igor Sapego 
Date:   2016-12-13T15:35:06Z

IGNITE-4421: Refactoring.

commit de7f1c498a23347edd85431460c0f69628e42fff
Author: Igor Sapego 
Date:   2016-12-13T16:53:56Z

IGNITE-4421: Added test.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4424:


 Summary: REPLICATED cache isn't synced across nodes
 Key: IGNITE-4424
 URL: https://issues.apache.org/jira/browse/IGNITE-4424
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov
Priority: Critical
 Fix For: 2.0


Replicated cache sometimes won't sync across nodes properly.
Cache should be configured with CacheWriteSynchronizationMode.FULL_SYNC and 
CacheRebalanceMode.SYNC
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Capacity Planning - Calculating Memory Usage

[Andrey Mashenkov]

Alexandr,

In addition. If expire policy is configured, there is additional overhead
to entries can be tracked by TtlManager.
This overhead is OnHeap and does not depend on cache MemoryMode (until
Ignite-3840 will be in master).

For now overhead is about 32-40 bytes (EntryWrapper itself) + (40-48) bytes
(ConcurrentSkipList node) per entry.



On Tue, Dec 13, 2016 at 10:37 AM, Alexandr Kuramshin 
wrote:

> Hello, Igniters,
>
> I'd like to represent updated article [1] about the subject.
>
> And I'll very appreciate your comments and questions about it.
>
> Please review.
>
> [1] http://apacheignite.gridgain.org/docs/capacity-planning
>
> --
> Thanks,
> Alexandr Kuramshin
>



-- 
С уважением,
Машенков Андрей Владимирович
Тел. +7-921-932-61-82

Best regards,
Andrey V. Mashenkov
Cerr: +7-921-932-61-82

[jira] [Created] (IGNITE-4423) ignite.binary().type(entity.getKeyType())==null before first cache.put()

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-4423:


 Summary: ignite.binary().type(entity.getKeyType())==null before 
first cache.put()
 Key: IGNITE-4423
 URL: https://issues.apache.org/jira/browse/IGNITE-4423
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov
 Attachments: BinTest.java

See attacheed test for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Apche Ignite PMC Chair Election

[Yakov Zhdanov]

Denis Magda

[jira] [Created] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4422:
--

 Summary: Define platform plugin API in Java
 Key: IGNITE-4422
 URL: https://issues.apache.org/jira/browse/IGNITE-4422
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4421:
---

 Summary: ODBC: SQLFetch fails if result set contains non-primitive 
column.
 Key: IGNITE-4421
 URL: https://issues.apache.org/jira/browse/IGNITE-4421
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.0


If any column of the result set is complex binary object (non primitive type), 
then {{SQLFetch}} fails upon call with the following message:
{noformat}
Error 01S01: Can not retrieve row column.
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4420) .NET: Improve documentation for query configuration combined with reflective serialization

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4420:
--

 Summary: .NET: Improve documentation for query configuration 
combined with reflective serialization
 Key: IGNITE-4420
 URL: https://issues.apache.org/jira/browse/IGNITE-4420
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


With automatic properties the situation is straightforward: mark property with 
[QuerySqlField].

With manual backing fields there may be some confusion, because reflective 
serializer operates on fields, and field names start with "_" in default naming 
convention. 

Make sure all situations are documented properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Apche Ignite PMC Chair Election

[Branko Čibej]

On 2016-12-10 21:24 (+0100), Dmitriy Setrakyan  wrote: 
> According to the discussion on the dev list [1], the following candidates
> were proposed for the Apache Ignite PMC Chair position:
> 
>  Vladimir Ozerov
>  Konstantin Boudnik
>  Valentin Kulichenko
>  Denis Magda
>  Branko Čibej


I'm mildly intrigued that anyone would put my name on a PMC Chair vote proposal 
without asking me first ... especially since I've not been subscribed to any of 
the mailing lists for a looong time now. Not that there's any danger of my 
being elected, but just for the record: I'm not a candidate, please do not 
waste any of your votes on me.

And since I have not been active in the community and have not contributed to 
the project for so long, nor do I expect this state of affairs to change in the 
foreseeable future, I'd like to take this opportunity to announce my 
resignation from the Ignite PMC.

My decision is final, and is the result of changing interests and personal 
circumstances. I wish you all the best of luck with the project and community.

-- Brane

Re: Capacity Planning - Calculating Memory Usage

[Denis Magda]

Alexander, great update, thanks.

Yakov, Alexey Scherbakov, Val, 

Please do the review first since you’re as the ones who deal a lot with 
performance and memory usage related questions.

—
Denis

> On Dec 12, 2016, at 11:37 PM, Alexandr Kuramshin  wrote:
> 
> Hello, Igniters,
> 
> I'd like to represent updated article [1] about the subject.
> 
> And I'll very appreciate your comments and questions about it.
> 
> Please review.
> 
> [1] http://apacheignite.gridgain.org/docs/capacity-planning
> 
> -- 
> Thanks,
> Alexandr Kuramshin

Re: [VOTE] Apche Ignite PMC Chair Election

[Andrey Novikov]

Denis Magda

On Tue, Dec 13, 2016 at 6:56 AM, Denis Magda  wrote:

> Cos,
>
> > The fact that some of the PMC members here still consider
> > themselves first as an employee of company X and only then the as a
> member of
> > Ignite PMC
>
> I consider myself as a free son of the Earth who lives his life the way he
> likes :) The rest is of the same priority.
>
> Well, the whole point of my previous reply is that no matter who you’re
> and who pays you it’s, eventually, up to you where and how to go.
>
> —
> Denis
>
> > On Dec 12, 2016, at 3:37 PM, Konstantin Boudnik  wrote:
> >
> > On Mon, Dec 12, 2016 at 12:12PM, Denis Magda wrote:
> >> Denis Magda
> >>
> >>
> >> Regardless of the fact that I’m a GridGain employee and that GridGain
> still
> >> represents the majority of our community, I would truly like to make our
> >
> > One's affiliation is mostly the fact of one's biography and quite
> irrelevant
> > for the Foundation. The fact that some of the PMC members here still
> consider
> > themselves first as an employee of company X and only then the as a
> member of
> > Ignite PMC is a strong indication that we need to revisit some of the
> lessons
> > from the incubation. Without a solid separation of church and the state,
> > errr  the project and where the paycheck is coming from - all the
> yearning
> > for "diversity" is just a wishful thinking.
> >
> > Cos
> >
> >> community more diversified and transparent and less dependent of
> GridGain.
> >> Being a PMC chair will motivate me to learn even more about Apache
> >> processes, principles and leverage the overall knowledge and fully
> relying
> >> on your support and experience of other open source project move our
> >> community to the diversified future.
> >>
> >> —
> >> Denis
> >>
> >>> On Dec 10, 2016, at 12:24 PM, Dmitriy Setrakyan 
> wrote:
> >>>
> >>> According to the discussion on the dev list [1], the following
> candidates
> >>> were proposed for the Apache Ignite PMC Chair position:
> >>>
> >>> Vladimir Ozerov
> >>> Konstantin Boudnik
> >>> Valentin Kulichenko
> >>> Denis Magda
> >>> Branko Čibej
> >>>
> >>> The vote is taking place on the dev list, however only votes from
> Apache
> >>> Ignite PMC members will be considered as binding.
> >>>
> >>> *Note that this is not +1 or -1 vote. Please reply to this email
> specifying
> >>> the name of your preferred candidate for the Ignite PMC chair position
> >>> (feel free to explain why).*
> >>>
> >>> The vote will go for 72 hours. Candidate who gets the most amount of
> votes
> >>> (not the majority) will be elected.
> >>>
> >>> Note, that I specifically removed my name from the list, because the
> whole
> >>> point is to rotate a PMC chair, and not to reelect one.
> >>>
> >>> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/DISCUSS-PMC-Chair-
> >>> rotation-time-td11941.html
> >>
>
>

[jira] [Created] (IGNITE-4419) .NET: Serilog integration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4419:
--

 Summary: .NET: Serilog integration
 Key: IGNITE-4419
 URL: https://issues.apache.org/jira/browse/IGNITE-4419
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.0


Serilog is another popular .NET logger: https://serilog.net/

Integrate with Ignite.NET, see NLog and log4net integrations: IGNITE-3279, 
IGNITE-3280



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4418) Web console: summary page is hangs if clusters list contain a huge cluster

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4418:
--

 Summary: Web console: summary page is hangs if clusters list 
contain a huge cluster
 Key: IGNITE-4418
 URL: https://issues.apache.org/jira/browse/IGNITE-4418
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov


I have a cluster with 1284 caches (with 1284 models).
When I open summary page it hangs for a 10-15 seconds.
No splash screen with loading progress shows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Anton Vinogradov]

Pgp signature seems to be correct, signed by sboikov.

Seems, that sonatype reason equals to http://repo.maven.apache.org/maven2
reason.

I've reasked infra to check logs.

On Tue, Dec 13, 2016 at 11:25 AM, Sergey Kozlov 
wrote:

> Geospatial and some other modules have been removed purposely.
>
> The key change between 1.7.0 and 1.8.0 for maven deployment is splitting
> cassandra module into two separate modules: cassandra-store and
> cassandra-serializers.
>
> On Tue, Dec 13, 2016 at 3:27 AM, Denis Magda  wrote:
>
> >
> > > On Dec 12, 2016, at 4:08 PM, Konstantin Boudnik 
> wrote:
> > >
> > > Interestingly enough, looking thought the artifacts in Maven, I see
> > > a whole bunch of the component that are pulled from the latest releases
> > yet
> > > are presented in the Maven. Say geospacial is only published up to
> > 1.2.0, etc.
> >
> > It looks weird to me as well. Could you start a separate discussion on
> the
> > dev list in order to trigger attention of the guys who usually take care
> > about Ignite’s build system?
> >
> > —
> > Denis
>
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: affinityCall in one distributed transaction

[Dmitriy Setrakyan]

On Tue, Dec 13, 2016 at 1:29 AM, Антон Чураев  wrote:

> Using JTA in current implementation Ignite is possible. But it is
> expensive, because currently Ignite does not support distributed
> transaction context within all grid.
>
> I think it would be right to devide task into two:
> 1) Add support of switching transactional context between multiple thread
> within single instance jvm;
>

Can you please suggest an API for it?


> 2) Using distributed memory for keeping transaction context;
>

What do you mean by distributed memory here?


>
> In my opinion, the first one is not so difficult to implement.
>
> 2016-12-13 1:29 GMT+03:00 Dmitriy Setrakyan :
>
> > Anton,
> >
> > Looking at this sequence, I don't see any way of achieving it other than
> > enrolling all transactions into one JTA transaction. If you seen another
> > way, can you please suggest it here?
> >
> > D.
> >
> > On Sat, Dec 10, 2016 at 2:07 PM, Антон Чураев 
> > wrote:
> >
> > > Dmitriy, it's ok
> > >
> > > To be abstract simple business transaction for execution payment
> > > (preparation done before)  from the card looks like:
> > > 1) Create a payment document (cache API);
> > > 2) Write-off funds from the payer's card;
> > > 2.1) Change in register #1 (cache API);
> > > 2.2) Change in register #2 (cache API);
> > > 2.3) Change in register #... (cache API);
> > > 2.4) Change limits of card (cache API);
> > > 3) Payment to service provider;
> > > 3.1) Change in the balance of business unit having the contract with
> > payer
> > > (cache API);
> > > 3.2) Change in the balance of business unit having the contract with
> > > provider (cache API);
> > > 3.3) Change in the balance of the account (cache API);
> > > 3.4.1) Some change in registers... (cache API);
> > > 3.4.2) ...;
> > > 3.3) ...
> > > 3.4) Invoke provider's API for billing payment of payer;
> > > 4) Formation of financial statements (it's possible to implement
> > off-line -
> > > in other transational)
> > > 4.1) ...
> > > 4.2) ...
> > >
> > > And all steps have been designed into separate microservices. And, of
> > > course, it have been designed via asynchronous transport.
> > > On the other hand it seems to be that implementation of coordination of
> > > 10-20 local transactions is not a good idea
> > >
> > > 2016-12-10 23:30 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Anton,
> > > >
> > > > Thanks for the explanation. I am sorry to keep asking questions on
> > this.
> > > > Can you change your example to include concrete Ignite calls on
> Compute
> > > or
> > > > Cache APIs (or other APIs)? I am still struggling to understand the
> > > > boundaries between business and Ignite logic.
> > > >
> > > > D.
> > > >
> > > > On Sat, Dec 10, 2016 at 5:46 AM, Антон Чураев 
> > > > wrote:
> > > >
> > > > > For example:
> > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > 2) Some application (like a business transactional coordinator)
> > > receives
> > > > > message via asynchronous transport. This application implements
> logic
> > > of
> > > > > calling different services sequentially or in parallel via
> > asynchronous
> > > > > transport.
> > > > > 3) Each service implement some little changes in a cache.
> > > > >
> > > > > Or:
> > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > 2) This transaction is implemented in microservice architecture
> > (large
> > > > > number microservices + asynchronous transport).
> > > > > 3) Each microservice implement some little changes in a cache.
> > > > >
> > > > > I think it is possible to implement distributed transactional using
> > XA
> > > > > coordinator outside Ignite and local transaction in each service.
> But
> > > its
> > > > > cost may be unacceptable especially in the case of using a large
> > number
> > > > of
> > > > > services.
> > > > >
> > > > > I think distributed transaction inside Ignite could be useful also
> > for
> > > > > using multiple ComputeTask in one transaction.
> > > > >
> > > > > 2016-12-09 21:45 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Sounds like you need a centralized JTA server for this type of
> > > purpose,
> > > > > no?
> > > > > > In that case, Ignite transactions can already merge into ongoing
> > JTA
> > > > > > transactions.
> > > > > >
> > > > > > I would prefer to see a distributed flow of events to fully
> > > understand
> > > > > the
> > > > > > issue. For example,
> > > > > >
> > > > > > Client
> > > > > >   - start transaction
> > > > > >   - send compute
> > > > > >
> > > > > > Server
> > > > > >   - receive compute
> > > > > >   - execute ...
> > > > > >   - execute ...
> > > > > >
> > > > > > etc.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Fri, Dec 9, 2016 at 1:26 AM, Антон Чураев <
> churaev...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > In some cases 

Re: affinityCall in one distributed transaction

[Антон Чураев]

Using JTA in current implementation Ignite is possible. But it is
expensive, because currently Ignite does not support distributed
transaction context within all grid.

I think it would be right to devide task into two:
1) Add support of switching transactional context between multiple thread
within single instance jvm;
2) Using distributed memory for keeping transaction context;

In my opinion, the first one is not so difficult to implement.

2016-12-13 1:29 GMT+03:00 Dmitriy Setrakyan :

> Anton,
>
> Looking at this sequence, I don't see any way of achieving it other than
> enrolling all transactions into one JTA transaction. If you seen another
> way, can you please suggest it here?
>
> D.
>
> On Sat, Dec 10, 2016 at 2:07 PM, Антон Чураев 
> wrote:
>
> > Dmitriy, it's ok
> >
> > To be abstract simple business transaction for execution payment
> > (preparation done before)  from the card looks like:
> > 1) Create a payment document (cache API);
> > 2) Write-off funds from the payer's card;
> > 2.1) Change in register #1 (cache API);
> > 2.2) Change in register #2 (cache API);
> > 2.3) Change in register #... (cache API);
> > 2.4) Change limits of card (cache API);
> > 3) Payment to service provider;
> > 3.1) Change in the balance of business unit having the contract with
> payer
> > (cache API);
> > 3.2) Change in the balance of business unit having the contract with
> > provider (cache API);
> > 3.3) Change in the balance of the account (cache API);
> > 3.4.1) Some change in registers... (cache API);
> > 3.4.2) ...;
> > 3.3) ...
> > 3.4) Invoke provider's API for billing payment of payer;
> > 4) Formation of financial statements (it's possible to implement
> off-line -
> > in other transational)
> > 4.1) ...
> > 4.2) ...
> >
> > And all steps have been designed into separate microservices. And, of
> > course, it have been designed via asynchronous transport.
> > On the other hand it seems to be that implementation of coordination of
> > 10-20 local transactions is not a good idea
> >
> > 2016-12-10 23:30 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Anton,
> > >
> > > Thanks for the explanation. I am sorry to keep asking questions on
> this.
> > > Can you change your example to include concrete Ignite calls on Compute
> > or
> > > Cache APIs (or other APIs)? I am still struggling to understand the
> > > boundaries between business and Ignite logic.
> > >
> > > D.
> > >
> > > On Sat, Dec 10, 2016 at 5:46 AM, Антон Чураев 
> > > wrote:
> > >
> > > > For example:
> > > > 1) Front-end sends a request to perform a complex transaction.
> > > > 2) Some application (like a business transactional coordinator)
> > receives
> > > > message via asynchronous transport. This application implements logic
> > of
> > > > calling different services sequentially or in parallel via
> asynchronous
> > > > transport.
> > > > 3) Each service implement some little changes in a cache.
> > > >
> > > > Or:
> > > > 1) Front-end sends a request to perform a complex transaction.
> > > > 2) This transaction is implemented in microservice architecture
> (large
> > > > number microservices + asynchronous transport).
> > > > 3) Each microservice implement some little changes in a cache.
> > > >
> > > > I think it is possible to implement distributed transactional using
> XA
> > > > coordinator outside Ignite and local transaction in each service. But
> > its
> > > > cost may be unacceptable especially in the case of using a large
> number
> > > of
> > > > services.
> > > >
> > > > I think distributed transaction inside Ignite could be useful also
> for
> > > > using multiple ComputeTask in one transaction.
> > > >
> > > > 2016-12-09 21:45 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > Sounds like you need a centralized JTA server for this type of
> > purpose,
> > > > no?
> > > > > In that case, Ignite transactions can already merge into ongoing
> JTA
> > > > > transactions.
> > > > >
> > > > > I would prefer to see a distributed flow of events to fully
> > understand
> > > > the
> > > > > issue. For example,
> > > > >
> > > > > Client
> > > > >   - start transaction
> > > > >   - send compute
> > > > >
> > > > > Server
> > > > >   - receive compute
> > > > >   - execute ...
> > > > >   - execute ...
> > > > >
> > > > > etc.
> > > > >
> > > > > D.
> > > > >
> > > > > On Fri, Dec 9, 2016 at 1:26 AM, Антон Чураев  >
> > > > wrote:
> > > > >
> > > > > > In some cases it is necessary to implement a transaction
> processing
> > > > logic
> > > > > > in several different application servers. In this case, working
> > with
> > > > > Ignite
> > > > > > cache will be performed within the various applications. But all
> > > these
> > > > > > changes must be made within the same distributed transaction.
> > > > > >
> > > > > > In my opinion this will require context transfer between the
> > threads
> > > > > within

Re: [RESULT] [VOTE] Apache Ignite 1.8.0 Release (RC1)

[Sergey Kozlov]

Geospatial and some other modules have been removed purposely.

The key change between 1.7.0 and 1.8.0 for maven deployment is splitting
cassandra module into two separate modules: cassandra-store and
cassandra-serializers.

On Tue, Dec 13, 2016 at 3:27 AM, Denis Magda  wrote:

>
> > On Dec 12, 2016, at 4:08 PM, Konstantin Boudnik  wrote:
> >
> > Interestingly enough, looking thought the artifacts in Maven, I see
> > a whole bunch of the component that are pulled from the latest releases
> yet
> > are presented in the Maven. Say geospacial is only published up to
> 1.2.0, etc.
>
> It looks weird to me as well. Could you start a separate discussion on the
> dev list in order to trigger attention of the guys who usually take care
> about Ignite’s build system?
>
> —
> Denis




-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: IGNITE-3727： why did not merge into the 1.8 version?

[Semyon Boikov]

Hi,

We had a lot of more priority issues so I somehow missed IGNITE-3732. As a
workaround it is possible to create special thread pool and when message is
sent to local node execute message listener there instead of
IgniteMessaging usage.

Thanks

On Sun, Dec 11, 2016 at 5:56 AM, Denis Magda  wrote:

> Alright, looks like I confused it with some other task initially.
>
> The ticket you’re talking about is still under review and looks abandoned
> https://issues.apache.org/jira/browse/IGNITE-3727 <
> https://issues.apache.org/jira/browse/IGNITE-3727>
>
> Dmitriy G., Sam, is the ticket ready for the merge?
>
> —
> Denis
>
> > On Dec 10, 2016, at 6:29 PM, 李玉珏@163 <18624049...@163.com> wrote:
> >
> > Denis，
> >
> > I found  the branch 3727:
> >
> > https://github.com/gridgain/apache-ignite/tree/ignite-3727-2
> >
> > But it appear that the code is not merged into the master?
> >
> > for example, IgniteMessagingImpl.java,the related code is still an old
> version,8 months ago.
> >
> >
> > 在 2016/12/10 22:56, Denis Magda 写道:
> >> Hi,
> >>
> >> It was released in 1.8. I’ve just checked git logs.
> >>
> >> How did you come up with such a conclusion? Something doesn't work on
> your side?
> >>
> >> —
> >> Denis
> >>
> >>> On Dec 10, 2016, at 5:39 AM, 李玉珏@163 <18624049...@163.com> wrote:
> >>>
> >>> Hi：
> >>>
> >>>
> >>> IGNITE-3727,this issue has been fixed and tested in september，why did
> not merge into the 1.8 version?
> >>>
> >>>
> >
>
>