Re: IGNITE-2766 Spring Cache Manager ReConnect Issue

[Rishi Yagnik]

Hi Val,

Committed changes on IGNITE-2786, would like you to review the
changes.Would you please review it ?

Thanks,

On Mon, Mar 27, 2017 at 6:11 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Rishi,
>
> You should be able to assign to tickets to yourself now.
>
> -Val
>
> On Mon, Mar 27, 2017 at 1:23 PM, Rishi Yagnik 
> wrote:
>
> > Hi Val,
> >
> > My user name is ryagnik
> >
> > Thanks,
> > Rishi
> >
> > On Mon, Mar 27, 2017 at 12:14 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Hi Rishi,
> > >
> > > What is your username in Jira? I will add you as a contributor.
> > >
> > > Also please go through [1] and [2] for all the details about our
> process.
> > >
> > > [1] https://ignite.apache.org/community/contribute.html#contribute
> > > [2] https://cwiki.apache.org/confluence/display/IGNITE/
> > Development+Process
> > >
> > > -Val
> > >
> > > On Sun, Mar 26, 2017 at 5:56 PM, Rishi Yagnik 
> > > wrote:
> > >
> > > > Hi Val,
> > > >
> > > > I started working on it but could not assign issue to me, how do I
> > assign
> > > > ticket to my self ?
> > > >
> > > > Do I need contributor access to contribute the fix ?
> > > >
> > > > Please clarify..
> > > >
> > > > Thanks,
> > > >
> > > > On Fri, Mar 24, 2017 at 12:10 AM, Rishi Yagnik <
> rishiyag...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Val,
> > > > >
> > > > > Sorry for the delay, I will work on the fix on weekend.
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > On Mon, Mar 13, 2017 at 12:08 PM, Rishi Yagnik <
> > rishiyag...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi Val,
> > > > >>
> > > > >> I will work on it in my spare time..
> > > > >>
> > > > >> Take Care,
> > > > >> Rishi
> > > > >>
> > > > >> > On Mar 13, 2017, at 10:54 AM, Valentin Kulichenko <
> > > > >> valentin.kuliche...@gmail.com> wrote:
> > > > >> >
> > > > >> > Hi Rishi,
> > > > >> >
> > > > >> > Can you please assign the ticket to yourself and create a pull
> > > request
> > > > >> as
> > > > >> > described in [1]?
> > > > >> >
> > > > >> > Let's follow the process :)
> > > > >> >
> > > > >> > [1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+
> > > > >> Contribute
> > > > >> >
> > > > >> > -Val
> > > > >> >
> > > > >> > On Sun, Mar 12, 2017 at 2:04 AM, ignite_dev2017 <
> > > > rishiyag...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Hi Val,
> > > > >> >>
> > > > >> >> The fix which we applied as follows with SpringCacheManager -
> > > > >> >>
> > > > >> >> 1) Design was to listen for ignite re connect event
> > > > >> >> 2) And clear the cache on reconnect
> > > > >> >>
> > > > >> >> See the following code below and let us know if this is
> helpful -
> > > > >> >>
> > > > >> >> In afterPropertiesSet -
> > > > >> >>
> > > > >> >> //Handles the reconnect event, on server crashes OR network
> > > failure,
> > > > >> client
> > > > >> >> connects to server and
> > > > >> >>// destroy the cache
> > > > >> >>IgnitePredicate lsnr = iEvt -> {
> > > > >> >>LOGGER.info("Received discovery event [iEvt=" +
> > > > iEvt.name()
> > > > >> +
> > > > >> >> ",
> > > > >> >> discovery=" + iEvt.shortDisplay() + ']');
> > > > >> >>
> > > > >> >>caches.keySet().forEach(key -> {
> > > > >> >>ignite.destroyCache(key);
> > > > >> >>caches.remove(key);
> > > > >> >>} );
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> Let me know if you see any side effects with the fix.
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> Rishi
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> View this message in context: http://apache-ignite-
> > > > >> >> developers.2346864.n4.nabble.com/IGNITE-2766-Spring-Cache-
> > > > >> >> Manager-ReConnect-Issue-tp15362.html
> > > > >> >> Sent from the Apache Ignite Developers mailing list archive at
> > > > >> Nabble.com.
> > > > >> >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Rishi Yagnik
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Rishi Yagnik
> > > >
> > >
> >
> >
> >
> > --
> > Rishi Yagnik
> >
>



-- 
Rishi Yagnik

[GitHub] ignite pull request #1688: IGNITE-2786 : SpringCache doesn't survive client ...

[ryagnik]

GitHub user ryagnik opened a pull request:

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

IGNITE-2786 : SpringCache doesn't survive client reconnect

The fix can be applied as follows with SpringCacheManager -

1) Design was to listen for ignite re connect event
2) And clear the cache on reconnect
3) Added logger to log reconnect information 

See the following code below and let us know if this is helpful -

In afterPropertiesSet -

//Handles the reconnect event, on server crashes OR network failure, client
connects to server and
// destroy the cache
IgnitePredicate lsnr = iEvt -> {
U.warn(log,"Received discovery event [iEvt=" + iEvt.name() + ", discovery=" 
+ iEvt.shortDisplay() + ']');

caches.keySet().forEach(key ->
{ ignite.destroyCache(key); caches.remove(key); }

);

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

$ git pull https://github.com/ryagnik/ignite IGNITE-2786

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

https://github.com/apache/ignite/pull/1688.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 #1688


commit 9cb6a2cc722989d9e9752aad67f5843d028e07f1
Author: Rishi Yagnik 
Date:   2017-03-29T02:44:21Z

IGNITE-2786 : Fix Spring Client reconnect issue using reconnect event 
mechanism.




---
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.
---

Re: Making News page more visible

[Denis Magda]

Hi Tom,

Welcome to the community! It’s great we have contributor like you.

BTW, what do you think on this?

> Second, can we anchor every piece of news [1] so that it can be referred 
> directly from other sources. Also it makes sense to add “Twitter”, “FB”, 
> “LinkedIn” icons close to every news so that we can promote them easily.

—
Denis

> On Mar 28, 2017, at 7:11 AM, Tom Diederich  wrote:
> 
> Looks much better! Thanks for making that change.
> 
> I've just joined the Apache Ignite community. Most of my career has been
> devoted to building and growing technical online communities. I'd be honored
> to help the Apache Ignite community grow via some modest social promotion,
> blogging -- anywhere I can be of service. So I'll be keeping my eyes open
> for suggestions, too, and also making some recommendations from time to
> time. 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Making-News-page-more-visible-tp15763p15846.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Getting Started with Apache Ignite - Part 1

[Denis Magda]

Dani, excellent job!

*Prachi*, could you publish the article to DZone and update Ignite’s blogging 
page? Since this will be a series of posts don’t add DZone version of the 
article to Ignite’s page but rather add a link to the Dani’s own blog right 
away.

*Dani*, to give more visibility to your work I would suggest registering your 
blog on IMC Planned aggregator:
https://www.imcplanet.org 
 
—
Denis

> On Mar 28, 2017, at 11:42 AM, Dani Traphagen  wrote:
> 
> Hi Igniters,
> 
> I'm working on a multi-part series on working with Apache Ignite and just
> released my first post today.
> 
> 
> This first post gives a conceptual basis to working with Ignite while
> follow up posts will work with code samples. Enjoy!
> 
> Here's a direct link to the post: Getting Started to Apache Ignite - Part 1.
> 
> 
> Cheers,
> Dani
> -- 
> Dani Traphagen | d...@gridgain.com
> Solutions Architect
> *GridGain*

Re: [PMCs] Seeking your help for ASF's 18th Anniversary

[Denis Magda]

Prachi, thanks! Merged.

> On Mar 28, 2017, at 11:59 AM, Prachi Garg  wrote:
> 
> Denis,
> 
> Please apply the attached patch.
> 
> -P
> 
> On Tue, Mar 28, 2017 at 9:34 AM, Denis Magda  > wrote:
> Igniters,
> 
> ASF needs you support. Please read below.
> 
> Prachi, please add this logo to Ignite site’s footer and make it refer to the 
> donation page [1]:
> https://blogs.apache.org/foundation/mediaresource/d67ca611-a57c-462d-ac23-95063f81d175
>  
> 
>  
>   
> >
> 
> [1] https://donate.apache.org  
> >
> 
> —
> Denis
> 
> > Begin forwarded message:
> >
> > From: Sally Khudairi >
> > Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> > Date: March 28, 2017 at 3:04:06 AM PDT
> > To: Sally Khudairi >, ASF 
> > Fundraising >
> > Reply-To: priv...@ignite.apache.org 
> > Reply-To: Sally Khudairi >
> >
> > Hello everyone --thank you for your patience. We are now live:
> >
> >  - NASDAQ GlobeNewswire 
> > https://globenewswire.com/news-release/2017/03/28/945724/0/en/The-Apache-Software-Foundation-Announces-18-Years-of-Open-Source-Leadership.html
> >  
> > 
> >  - ASF "Foundation" blog https://s.apache.org/DHlr 
> > 
> >  - @TheASF Twitter feed 
> > https://twitter.com/TheASF/status/846663405851291650 
> > 
> >  - NEW! ASF LinkedIn page 
> > https://www.linkedin.com/company/the-apache-software-foundation 
> > 
> >
> > ...as well as to annou...@apache.org  and our 
> > dedicated media/analyst list. This will appear on the apache.org 
> >  homepage later today.
> >
> > We encourage you to spread the word on your project pages and Twitter 
> > feeds, personal sites, as well as any employers/partners/* as appropriate. 
> > The relevant assets are:
> >
> >  - Support Apache logo 
> > https://blogs.apache.org/foundation/mediaresource/d67ca611-a57c-462d-ac23-95063f81d175
> >  
> > 
> >  - individual donations links https://donate.apache.org/ 
> >  (immediate) and 
> > http://apache.org/foundation/contributing.html 
> >  (will be updated later 
> > today)
> >
> > Thank you in advance for all your help and incredible support!
> >
> > Kind regards,
> > Sally
> >
> > = = = = =
> > vox +1 617 921 8656 
> > gvox +1 646 598 4616 
> > skype sallykhudairi
> >
> >
> > From: Sally Khudairi >
> > To: ASF Marketing & Publicity >; 
> > ASF Fundraising >
> > Sent: Sunday, March 26, 2017 7:14 PM
> > Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> >
> > Hello PMCs --a heads-up that our launch tomorrow has been postponed due to 
> > an outstanding issue with one of our payment processing systems.
> >
> > We are working on the issue and are hoping to announce at 6AM ET on Tuesday 
> > 28 March. Fingers crossed.
> >
> > I'll confirm once we're live. We appreciate your patience!
> >
> > Kind thanks,
> > Sally
> >
> > = = = = =
> > vox +1 617 921 8656 
> > gvox +1 646 598 4616 
> > skype sallykhudairi
> >
> >
> > From: Sally Khudairi >
> > To: ASF Marketing & Publicity >; 
> > Apache Software Foundation  > >
> > Sent: Friday, March 24, 2017 4:10 PM
> > Subject: [PMCs] Seeking your help for ASF's 18th Anniversary
> >
> > Hello Apache PMCs (in blindcopy) --I trust you are well.
> >
> > I wanted to give you a heads-up that at 6AM ET this Monday, 27 March, we 
> > will be issuing a press release announcing the ASF's 18th Anniversary. This 
> > will be posted across the ASF's usual communication channels 
> > (blogs.apache.org , annou...@apache.org 
> > 

Re: IGNITE-4188, savepoints with atomic cache?

[Denis Magda]

If we want to make the exception based approach the default one then the task 
has to be released in 2.0.

Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the code 
freeze data (April 14)?

—
Denis

> On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan  wrote:
> 
> On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin 
> wrote:
> 
>> I think updating an Atomic cache from within a transaction perfectly makes
>> sense. For example for some kind of operations logging and so forth. Still
>> I agree that this can be error prone and forbidden by default. I agree with
>> Yakov that by default we should throw an exception and have some kind of
>> flag (on cache or on TX?) to be able to explicitly enable this behavior.
>> 
> 
> 
> Agree, this sounds like a good idea.

[jira] [Created] (IGNITE-4875) Allow execution over explicit set of partitions for every non-SQL query type with data integrity guarantees.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4875:
-

 Summary: Allow execution over explicit set of partitions for every 
non-SQL query type with data integrity guarantees.
 Key: IGNITE-4875
 URL: https://issues.apache.org/jira/browse/IGNITE-4875
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Alexei Scherbakov
 Fix For: 2.1


The ticket has the same origin as IGNITE-4523.

I've just split SQL and non-SQL parts for the sake of clality.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [GridCachePartitionExchangeManager] Pending transaction deadlock detection futures

[Valentin Kulichenko]

cross-posting to dev list.

Guys,

Does anyone have an idea why client mode in Visor affects behavior? I
thought we already forced client mode there, no?

Alexey, you should know the answer. Can you please take a look at this
thread?

-Val

On Tue, Mar 28, 2017 at 7:02 AM, ght230  wrote:

> Yes,I use custom build.
>
> Today I tried to set Ignition.setClientMode(true) for command "open" of the
> visorcmd.
>
> It seems the visorcmd will not stuck the whole cluster again.
>
> Is there anything wrong in "ClientMode" of the visorcmd?
>
>
>
> --
> View this message in context: http://apache-ignite-users.705
> 18.x6.nabble.com/GridCachePartitionExchangeManager-Pending-
> transaction-deadlock-detection-futures-tp11362p11501.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Getting Started with Apache Ignite - Part 1

[Dani Traphagen]

Thanks Dmitriy!

On Tue, Mar 28, 2017 at 11:48 AM Dmitriy Setrakyan 
wrote:

> Very nice blog, really enjoyed reading it.
>
> On Tue, Mar 28, 2017 at 11:42 AM, Dani Traphagen 
> wrote:
>
> > Hi Igniters,
> >
> > I'm working on a multi-part series on working with Apache Ignite and just
> > released my first post today.
> > 
> >
> > This first post gives a conceptual basis to working with Ignite while
> > follow up posts will work with code samples. Enjoy!
> >
> > Here's a direct link to the post: Getting Started to Apache Ignite - Part
> > 1.
> > 
> >
> > Cheers,
> > Dani
> > --
> > Dani Traphagen | d...@gridgain.com
> > Solutions Architect
> > *GridGain*
> >
>
-- 
Dani Traphagen | d...@gridgain.com
Solutions Architect
*GridGain*

Re: Adding ML to Ignite, IGNITE-4572

[alpercakan]

Hi,
I am Alper. I am a computer engineering and mathematics (as double major)
student with great interest in machine learning. I wish to participate in
GSOC - 2017 and I've been interested in this "issue" for a while. I think
that my skills fits this project and that I can really be useful and
contribute. Can you please help me about where I need to start from?
Thank you.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p15871.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: [PMCs] Seeking your help for ASF's 18th Anniversary

[Prachi Garg]

Denis,

Please apply the attached patch.

-P

On Tue, Mar 28, 2017 at 9:34 AM, Denis Magda  wrote:

> Igniters,
>
> ASF needs you support. Please read below.
>
> Prachi, please add this logo to Ignite site’s footer and make it refer to
> the donation page [1]:
> https://blogs.apache.org/foundation/mediaresource/d67ca611-a57c-462d-ac23-
> 95063f81d175  d67ca611-a57c-462d-ac23-95063f81d175>
>
> [1] https://donate.apache.org 
>
> —
> Denis
>
> > Begin forwarded message:
> >
> > From: Sally Khudairi 
> > Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> > Date: March 28, 2017 at 3:04:06 AM PDT
> > To: Sally Khudairi , ASF Fundraising <
> fundrais...@apache.org>
> > Reply-To: priv...@ignite.apache.org
> > Reply-To: Sally Khudairi 
> >
> > Hello everyone --thank you for your patience. We are now live:
> >
> >  - NASDAQ GlobeNewswire https://globenewswire.com/
> news-release/2017/03/28/945724/0/en/The-Apache-
> Software-Foundation-Announces-18-Years-of-Open-Source-Leadership.html
> >  - ASF "Foundation" blog https://s.apache.org/DHlr
> >  - @TheASF Twitter feed https://twitter.com/TheASF/
> status/846663405851291650
> >  - NEW! ASF LinkedIn page https://www.linkedin.com/
> company/the-apache-software-foundation
> >
> > ...as well as to annou...@apache.org and our dedicated media/analyst
> list. This will appear on the apache.org homepage later today.
> >
> > We encourage you to spread the word on your project pages and Twitter
> feeds, personal sites, as well as any employers/partners/* as appropriate.
> The relevant assets are:
> >
> >  - Support Apache logo https://blogs.apache.org/
> foundation/mediaresource/d67ca611-a57c-462d-ac23-95063f81d175
> >  - individual donations links https://donate.apache.org/ (immediate)
> and http://apache.org/foundation/contributing.html (will be updated later
> today)
> >
> > Thank you in advance for all your help and incredible support!
> >
> > Kind regards,
> > Sally
> >
> > = = = = =
> > vox +1 617 921 8656
> > gvox +1 646 598 4616
> > skype sallykhudairi
> >
> >
> > From: Sally Khudairi 
> > To: ASF Marketing & Publicity ; ASF Fundraising <
> fundrais...@apache.org>
> > Sent: Sunday, March 26, 2017 7:14 PM
> > Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> >
> > Hello PMCs --a heads-up that our launch tomorrow has been postponed due
> to an outstanding issue with one of our payment processing systems.
> >
> > We are working on the issue and are hoping to announce at 6AM ET on
> Tuesday 28 March. Fingers crossed.
> >
> > I'll confirm once we're live. We appreciate your patience!
> >
> > Kind thanks,
> > Sally
> >
> > = = = = =
> > vox +1 617 921 8656
> > gvox +1 646 598 4616
> > skype sallykhudairi
> >
> >
> > From: Sally Khudairi 
> > To: ASF Marketing & Publicity ; Apache Software
> Foundation 
> > Sent: Friday, March 24, 2017 4:10 PM
> > Subject: [PMCs] Seeking your help for ASF's 18th Anniversary
> >
> > Hello Apache PMCs (in blindcopy) --I trust you are well.
> >
> > I wanted to give you a heads-up that at 6AM ET this Monday, 27 March, we
> will be issuing a press release announcing the ASF's 18th Anniversary. This
> will be posted across the ASF's usual communication channels (
> blogs.apache.org, annou...@apache.org ,
> @TheASF Twitter feed, and ASF LinkedIn page).
> >
> > Many of the achievements highlighted in the press release are a direct
> result of your efforts :-)
> >
> > Coupled with this announcement is our interest in boosting ASF
> fundraising efforts in the form of individual donations. We will be
> launching our new "Support Apache" campaign, and are inviting folks to make
> a donation of any size (if possible) as a one-time donation or on a
> recurring basis.
> >
> > To that end, we are asking all PMCs to add the Support Apache logo
> https://s.apache.org/SupportApache  to
> your project pages with a link to the campaign when we go live next week. I
> will confirm the link when we're live.
> >
> > Thank you in advance for helping spread the word to your communities.
> Also, if there are any organizations involved with your projects that may
> be interested in ASF Sponsorship, we'd love to hear about it.
> >
> > We appreciate all your support in helping us continue to build for our
> future.
> >
> > Kindest regards,
> > Sally
> >
> >
> > = = = = =
> > vox +1 617 921 8656
> > gvox +1 646 598 4616
> > skype sallykhudairi
> >
> >
> >
> >
>
>

Re: IGNITE-4188, savepoints with atomic cache?

[Dmitriy Setrakyan]

On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin 
wrote:

> I think updating an Atomic cache from within a transaction perfectly makes
> sense. For example for some kind of operations logging and so forth. Still
> I agree that this can be error prone and forbidden by default. I agree with
> Yakov that by default we should throw an exception and have some kind of
> flag (on cache or on TX?) to be able to explicitly enable this behavior.
>


Agree, this sounds like a good idea.

Re: IGNITE-4188, savepoints with atomic cache?

[Sergi Vladykin]

I think updating an Atomic cache from within a transaction perfectly makes
sense. For example for some kind of operations logging and so forth. Still
I agree that this can be error prone and forbidden by default. I agree with
Yakov that by default we should throw an exception and have some kind of
flag (on cache or on TX?) to be able to explicitly enable this behavior.

Sergi

2017-03-28 21:51 GMT+03:00 Dmitriy Setrakyan :

> On Tue, Mar 28, 2017 at 11:42 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Dmitry,
> >
> > Transaction is not started on a particular cache, it's separate top-level
> > API. You can then include operations on different caches, like this:
> >
> > try (Transaction tx = ignite.transactions.txStart()) {
> > cache1.put(..);
> > cache2.put(..);
> > cache3.put(..);
> >
> > tx.commit();
> > }
> >
> > In the code above it's easy to think that all three operations are
> enlisted
> > in transaction, but if one of the caches happens to be atomic (due to
> > misconfiguration, for example), that's actually not true. And we don't
> even
> > warn user about this.
> >
>
> Got it.
>
> But what if a user really needs to update an atomic cache from within some
> transactional logic? I think we should allow it, but print out an warning
> to the log on per-cache basis the first time we see some atomic cache used
> from within a transaction.
>
> D.
>

Re: Continuations for services

[Valentin Kulichenko]

Vova,

Take a look at GridJobProcessor#processJobExecuteRequest method. In
particular, I'm talking about this piece of code:

if (ctx.localNodeId().equals(node.id())) {
// Always execute in another thread for local node.
executeAsync(job);

// No sync execution.
job = null;
}

executeAsync() method simply submits the job to public pool. This happens
every time job is executed locally and I'm having hard time understanding
why. In my view it negatively affects performance as we do context switch,
and creates yet another condition for starvation. If user executes it
synchronously, it doesn't make sense.

BTW, we don't do the same for services. If a service proxy is created for a
service which is available locally, we just return this instance. When user
invokes a method, it will be executed synchronously in the same thread.

-Val

On Tue, Mar 28, 2017 at 12:59 AM, Vladimir Ozerov 
wrote:

> Valya,
>
> Could you please point me where we delegate thread to another pool? I
> remember we did something around this when working with some streamer
> problems.
>
> On Tue, Mar 28, 2017 at 4:18 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Vova,
> >
> > Agree, I already merged IGNITE-4802.
> >
> > However, I'm still interested why we always switch to another thread when
> > executing a job locally. Does anyone have an idea why we do this?
> >
> > -Val
> >
> > On Sat, Mar 25, 2017 at 7:22 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Valya,
> > >
> > > I don't think it will resolve all the cases. For example, what if I
> > execute
> > > remote job from another job? "Remoteness" could be caused by job natire
> > > (broadcast), specific cluster group, or affinity call/run on remote
> key.
> > > Also starvation is possible not only on local node, but between nodes,
> > and
> > > in this case separate pool is the only reliable solution.
> > >
> > > On Sat, Mar 25, 2017 at 1:50 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Folks,
> > > >
> > > > I tend to think that a separate pool for services is not right
> > solution.
> > > >
> > > > We currently execute any new compute job in a separate thread, even
> if
> > > > we're already in the public pool (see code in
> > > > GridJobProcessor#processJobExecuteRequest). What is the reason for
> > this?
> > > > When a job synchronously executes another job on the same node, can
> we
> > > just
> > > > execute it in the same thread? This seems to fix all starvation
> issues
> > > > discussed in this thread.
> > > >
> > > > Am I missing something?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 9, 2017 at 2:32 AM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > OK, I created it: https://issues.apache.org/
> jira/browse/IGNITE-4802
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Mar 9, 2017 at 9:58 AM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > >> Valya,
> > > > >>
> > > > >> Not yet.
> > > > >>
> > > > >> On Thu, Mar 9, 2017 at 11:50 AM, Valentin Kulichenko <
> > > > >> valentin.kuliche...@gmail.com> wrote:
> > > > >>
> > > > >> > Vladimir,
> > > > >> >
> > > > >> > This makes sense to me. Is there a ticket for separate thread
> pool
> > > for
> > > > >> > services?
> > > > >> >
> > > > >> > -Val
> > > > >> >
> > > > >> > On Thu, Mar 9, 2017 at 2:52 AM, Dmitriy Setrakyan <
> > > > >> dsetrak...@apache.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Vladimr, it sounds like what you are suggesting is allowing
> > users
> > > > >> specify
> > > > >> > > named executors in configuration and then use them from code,
> > > > right? I
> > > > >> > > think I like this idea very much.
> > > > >> > >
> > > > >> > > On Wed, Mar 8, 2017 at 1:46 PM, Vladimir Ozerov <
> > > > voze...@gridgain.com
> > > > >> >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Continuations is not very good idea. It is useful if user
> has
> > > > simple
> > > > >> > > logic
> > > > >> > > > when one job calls another from within the same
> > execute/run/call
> > > > >> > method.
> > > > >> > > > But if you have complex logic with OOP abstractions and
> > reusable
> > > > >> > > > components, nested job call can be located many stack frames
> > > down
> > > > >> from
> > > > >> > > > parent job. In this case continuations are unusable.
> > > > >> > > >
> > > > >> > > > More convenient approach is to map separate jobs to separate
> > > > thread
> > > > >> > > pools.
> > > > >> > > > This technique is successfully employed in Hazelcast. You
> just
> > > > >> define
> > > > >> > > > additional executors and say that job A is to be executed
> one
> > > > thread
> > > > >> > > pool,
> > > > >> > > > and job B on another.
> > > > >> > > >
> > > > >> > > > The same technique is applicable for services:
> > > > >> > > >
> > > > >> > > > class MyService implements Service {
> > > > >> > > > @IgniteInstanceResource
> 

Re: IGNITE-4188, savepoints with atomic cache?

[Dmitriy Setrakyan]

On Tue, Mar 28, 2017 at 11:42 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> Transaction is not started on a particular cache, it's separate top-level
> API. You can then include operations on different caches, like this:
>
> try (Transaction tx = ignite.transactions.txStart()) {
> cache1.put(..);
> cache2.put(..);
> cache3.put(..);
>
> tx.commit();
> }
>
> In the code above it's easy to think that all three operations are enlisted
> in transaction, but if one of the caches happens to be atomic (due to
> misconfiguration, for example), that's actually not true. And we don't even
> warn user about this.
>

Got it.

But what if a user really needs to update an atomic cache from within some
transactional logic? I think we should allow it, but print out an warning
to the log on per-cache basis the first time we see some atomic cache used
from within a transaction.

D.

Re: Getting Started with Apache Ignite - Part 1

[Dmitriy Setrakyan]

Very nice blog, really enjoyed reading it.

On Tue, Mar 28, 2017 at 11:42 AM, Dani Traphagen  wrote:

> Hi Igniters,
>
> I'm working on a multi-part series on working with Apache Ignite and just
> released my first post today.
> 
>
> This first post gives a conceptual basis to working with Ignite while
> follow up posts will work with code samples. Enjoy!
>
> Here's a direct link to the post: Getting Started to Apache Ignite - Part
> 1.
> 
>
> Cheers,
> Dani
> --
> Dani Traphagen | d...@gridgain.com
> Solutions Architect
> *GridGain*
>

Re: IGNITE-4188, savepoints with atomic cache?

[Valentin Kulichenko]

Dmitry,

Transaction is not started on a particular cache, it's separate top-level
API. You can then include operations on different caches, like this:

try (Transaction tx = ignite.transactions.txStart()) {
cache1.put(..);
cache2.put(..);
cache3.put(..);

tx.commit();
}

In the code above it's easy to think that all three operations are enlisted
in transaction, but if one of the caches happens to be atomic (due to
misconfiguration, for example), that's actually not true. And we don't even
warn user about this.

-Val

On Tue, Mar 28, 2017 at 11:28 AM, Dmitriy Setrakyan 
wrote:

> I think an exception should be thrown if someone tries to start a
> transaction on an atomic cache. Throwing an exception at the "put(...)"
> time seems late and counter-intuitive.
>
> However, if a user starts a transaction on a transactional cache, say
> CacheA, and inside that transaction updates an entry from a different
> atomic cache, say CacheB, then such update should be allowed in my view,
> because the transaction was started on a completely different cache.
>
> Does this make sense?
>
> D.
>
> On Tue, Mar 28, 2017 at 11:22 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I actually think exception makes sense here. Currently it's very error
> > prone - the same code can behave differently depending on configuration.
> > And at the same time I can't imagine a use case which implies using
> atomic
> > operation within a transaction on purpose. If someone ever does this, it
> > would most likely be done by mistake.
> >
> > -Val
> >
> > On Tue, Mar 28, 2017 at 10:13 AM, Denis Magda  wrote:
> >
> > > Yakov,
> > >
> > > My vote goes for the current behavior - an atomic operation is applied
> > > right away if it’s a part of a transaction. It’s better not to break
> > > compatibility here, there are already to many incompatible changes in
> > 2.0.
> > >
> > > —
> > > Denis
> > >
> > > > On Mar 28, 2017, at 3:08 AM, Yakov Zhdanov 
> > wrote:
> > > >
> > > > As far as I know operations on atomic caches are applied immediately
> > > > dishonoring any tx context.
> > > >
> > > > I would suggest that atomic cache update operation called from active
> > tx
> > > > throws illegal state exception, unless user intentionally permits
> this
> > > > update by calling atomicCache.withAllowInTx() (similar to
> > > withSkipStore()).
> > > >
> > > > Thoughts?
> > > >
> > > > --Yakov
> > >
> > >
> >
>

Getting Started with Apache Ignite - Part 1

[Dani Traphagen]

Hi Igniters,

I'm working on a multi-part series on working with Apache Ignite and just
released my first post today.


This first post gives a conceptual basis to working with Ignite while
follow up posts will work with code samples. Enjoy!

Here's a direct link to the post: Getting Started to Apache Ignite - Part 1.


Cheers,
Dani
-- 
Dani Traphagen | d...@gridgain.com
Solutions Architect
*GridGain*

Re: Adding ML to Ignite, IGNITE-4572

[Dmitriy Setrakyan]

+100

Great feature! I too would like to see a list of tickets required for the
release.

D.

On Tue, Mar 28, 2017 at 11:24 AM, Denis Magda  wrote:

> Unbelievable, that’s astonishing we can already release the distributed
> algebra support in the beta state. Please share the tasks you’re planning
> to work on right after the release.
>
> —
> Denis
>
> > On Mar 28, 2017, at 11:12 AM, nivanov  wrote:
> >
> > Just a quick follow up...
> >
> > We've made some good progress on the initial code implementation in the
> last
> > couple of months and I think we'll make it on time to release a early
> "beta"
> > version of the IgniteML (a.k.a distributed math) for 2.0 release.
> >
> >
> >
> > --
> > View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-
> IGNITE-4572-tp13936p15858.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
>
>

Re: IGNITE-4188, savepoints with atomic cache?

[Dmitriy Setrakyan]

I think an exception should be thrown if someone tries to start a
transaction on an atomic cache. Throwing an exception at the "put(...)"
time seems late and counter-intuitive.

However, if a user starts a transaction on a transactional cache, say
CacheA, and inside that transaction updates an entry from a different
atomic cache, say CacheB, then such update should be allowed in my view,
because the transaction was started on a completely different cache.

Does this make sense?

D.

On Tue, Mar 28, 2017 at 11:22 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> I actually think exception makes sense here. Currently it's very error
> prone - the same code can behave differently depending on configuration.
> And at the same time I can't imagine a use case which implies using atomic
> operation within a transaction on purpose. If someone ever does this, it
> would most likely be done by mistake.
>
> -Val
>
> On Tue, Mar 28, 2017 at 10:13 AM, Denis Magda  wrote:
>
> > Yakov,
> >
> > My vote goes for the current behavior - an atomic operation is applied
> > right away if it’s a part of a transaction. It’s better not to break
> > compatibility here, there are already to many incompatible changes in
> 2.0.
> >
> > —
> > Denis
> >
> > > On Mar 28, 2017, at 3:08 AM, Yakov Zhdanov 
> wrote:
> > >
> > > As far as I know operations on atomic caches are applied immediately
> > > dishonoring any tx context.
> > >
> > > I would suggest that atomic cache update operation called from active
> tx
> > > throws illegal state exception, unless user intentionally permits this
> > > update by calling atomicCache.withAllowInTx() (similar to
> > withSkipStore()).
> > >
> > > Thoughts?
> > >
> > > --Yakov
> >
> >
>

Re: Adding ML to Ignite, IGNITE-4572

[Denis Magda]

Unbelievable, that’s astonishing we can already release the distributed algebra 
support in the beta state. Please share the tasks you’re planning to work on 
right after the release.

—
Denis

> On Mar 28, 2017, at 11:12 AM, nivanov  wrote:
> 
> Just a quick follow up...
> 
> We've made some good progress on the initial code implementation in the last
> couple of months and I think we'll make it on time to release a early "beta"
> version of the IgniteML (a.k.a distributed math) for 2.0 release. 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p15858.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: IGNITE-4188, savepoints with atomic cache?

[Valentin Kulichenko]

I actually think exception makes sense here. Currently it's very error
prone - the same code can behave differently depending on configuration.
And at the same time I can't imagine a use case which implies using atomic
operation within a transaction on purpose. If someone ever does this, it
would most likely be done by mistake.

-Val

On Tue, Mar 28, 2017 at 10:13 AM, Denis Magda  wrote:

> Yakov,
>
> My vote goes for the current behavior - an atomic operation is applied
> right away if it’s a part of a transaction. It’s better not to break
> compatibility here, there are already to many incompatible changes in 2.0.
>
> —
> Denis
>
> > On Mar 28, 2017, at 3:08 AM, Yakov Zhdanov  wrote:
> >
> > As far as I know operations on atomic caches are applied immediately
> > dishonoring any tx context.
> >
> > I would suggest that atomic cache update operation called from active tx
> > throws illegal state exception, unless user intentionally permits this
> > update by calling atomicCache.withAllowInTx() (similar to
> withSkipStore()).
> >
> > Thoughts?
> >
> > --Yakov
>
>

Re: Adding ML to Ignite, IGNITE-4572

[nivanov]

Just a quick follow up...

We've made some good progress on the initial code implementation in the last
couple of months and I think we'll make it on time to release a early "beta"
version of the IgniteML (a.k.a distributed math) for 2.0 release. 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p15858.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Apache Ignite 2.0 Release

[nivanov]

I think we can make it on time to add IgniteML (a.k.a. distributed math) to
2.0 release pipeline. 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-0-Release-tp15690p15857.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Ignite-4795 - ready for review

[Andrey Gura]

Dmitry, see JIRA ticket for review comments.

On Mon, Mar 27, 2017 at 6:13 PM, Denis Magda  wrote:
> Hello Dmitriy, thanks! Someone will have a look at your changes soon. Sorry 
> for the delay.
>
> —
> Denis
>
>> On Mar 27, 2017, at 3:24 AM, Дмитрий Рябов  wrote:
>>
>> Hello, can anyone review this issue?
>>
>> 2017-03-20 16:33 GMT+03:00 Дмитрий Рябов :
>>
>>> Done.
>>>
>>> 2017-03-20 16:30 GMT+03:00 Антон Чураев :
>>>
 Dmitry, thank you!

 Could you please also change issue status to "Patch available".

 2017-03-20 16:01 GMT+03:00 Дмитрий Рябов :

> Hello, community. Please, review and/or suggest something about
 javadocs of
> transactions.
>
> PR: https://github.com/apache/ignite/pull/1630/files
>
> JIRA: https://issues.apache.org/jira/browse/IGNITE-4795
>



 --
 С уважением,
 Чураев Антон

>>>
>>>
>

Re: distributed transaction of non-single coordinator

[Denis Magda]

Aleksey,

Do you have a ticket for this? Could you briefly list what exactly was done and 
how the things work.

—
Denis

> On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Hi, Igniters! I 've made implementation of transactions of non-single
> coordinator. Here you can start transaction in one thread and commit it in
> another thread.
> Take a look on it. Give your thoughts on it.
> 
> https://github.com/voipp/ignite/pull/10/commits/3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
> 
> пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin :
> 
>> You know better, go ahead! :)
>> 
>> Sergi
>> 
>> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV :
>> 
>>> we've discovered several problems regarding your "accumulation"
>>> approach.These are
>>> 
>>>   1. perfomance issues when transfering data from temporary cache to
>>>   permanent one. Keep in mind big deal of concurent transactions in
>>> Service
>>>   commiter
>>>   2. extreme memory load when keeping temporary cache in memory
>>>   3. As long as user is not acquainted with ignite, working with cache
>>>   must be transparent for him. Keep this in mind. User's node can
>> evaluate
>>>   logic with no transaction at all, so we should deal with both types of
>>>   execution flow : transactional and non-transactional.Another one
>>> problem is
>>>   transaction id support at the user node. We would have handled all
>> this
>>>   issues and many more.
>>>   4. we cannot pessimistically lock entity.
>>> 
>>> As a result, we decided to move on building distributed transaction. We
>> put
>>> aside your "accumulation" approach until we realize how to solve
>>> difficulties above .
>>> 
>>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin :
>>> 
 The problem "How to run millions of entities, and millions of
>> operations
>>> on
 a single Pentium3" is out of scope here. Do the math, plan capacity
 reasonably.
 
 Sergi
 
 2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV >> :
 
> hmm, If we have millions of entities, and millions of operations,
>> would
 not
> this approache lead to memory overflow and perfomance degradation
> 
> чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
>> sergi.vlady...@gmail.com
 :
> 
>> 1. Actually you have to check versions on all the values you have
>>> read
>> during the tx.
>> 
>> For example if we have [k1 => v1, k2 => v2] and do:
>> 
>> put(k1, get(k2) + 5)
>> 
>> We have to remember the version for k2. This logic can be
>> relatively
> easily
>> encapsulated in a framework atop of Ignite. You need to implement
>> one
 to
>> make all this stuff usable.
>> 
>> 2. I suggest to avoid any locking here, because you easily will end
>>> up
> with
>> deadlocks. If you do not have too frequent updates for your keys,
>> optimistic approach will work just fine.
>> 
>> Theoretically in the Committer Service you can start a thread for
>> the
>> lifetime of the whole distributed transaction, take a lock on the
>> key
> using
>> IgniteCache.lock(K key) before executing any Services, wait for all
>>> the
>> services to complete, execute optimistic commit in the same thread
 while
>> keeping this lock and then release it. Notice that all the Ignite
>> transactions inside of all Services must be optimistic here to be
>>> able
 to
>> read this locked key.
>> 
>> But again I do not recommend you using this approach until you
>> have a
>> reliable deadlock avoidance scheme.
>> 
>> Sergi
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV <
>>> alkuznetsov...@gmail.com
> :
>> 
>>> Yeah, now i got it.
>>> There are some doubts on this approach
>>> 1) During optimistic commit phase, when you assure no one altered
>>> the
>>> original values, you must check versions of other dependent keys.
>>> How
>> could
>>> we obtain those keys(in an automative manner, of course) ?
>>> 2) How could we lock a key before some Service A introduce
>> changes?
 So
> no
>>> other service is allowed to change this key-value?(sort of
 pessimistic
>>> blocking)
>>> May be you know some implementations of such approach ?
>>> 
>>> ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
>>> :
>>> 
 Thank you very much for help.  I will answer later.
 
 ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin <
> sergi.vlady...@gmail.com
>>> :
 
 All the services do not update key in place, but only generate
>>> new
> keys
 augmented by otx and store the updated value in the same cache
>> +
>> remember
 the keys and versions participating in the transaction in some
> 

Fwd: [PMCs] Seeking your help for ASF's 18th Anniversary

[Denis Magda]

Igniters,

ASF needs you support. Please read below.

Prachi, please add this logo to Ignite site’s footer and make it refer to the 
donation page [1]:
https://blogs.apache.org/foundation/mediaresource/d67ca611-a57c-462d-ac23-95063f81d175
 


[1] https://donate.apache.org 

—
Denis

> Begin forwarded message:
> 
> From: Sally Khudairi 
> Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> Date: March 28, 2017 at 3:04:06 AM PDT
> To: Sally Khudairi , ASF Fundraising 
> Reply-To: priv...@ignite.apache.org
> Reply-To: Sally Khudairi 
> 
> Hello everyone --thank you for your patience. We are now live:
> 
>  - NASDAQ GlobeNewswire 
> https://globenewswire.com/news-release/2017/03/28/945724/0/en/The-Apache-Software-Foundation-Announces-18-Years-of-Open-Source-Leadership.html
>  - ASF "Foundation" blog https://s.apache.org/DHlr
>  - @TheASF Twitter feed https://twitter.com/TheASF/status/846663405851291650
>  - NEW! ASF LinkedIn page 
> https://www.linkedin.com/company/the-apache-software-foundation
> 
> ...as well as to annou...@apache.org and our dedicated media/analyst list. 
> This will appear on the apache.org homepage later today.
> 
> We encourage you to spread the word on your project pages and Twitter feeds, 
> personal sites, as well as any employers/partners/* as appropriate. The 
> relevant assets are:
> 
>  - Support Apache logo 
> https://blogs.apache.org/foundation/mediaresource/d67ca611-a57c-462d-ac23-95063f81d175
>  - individual donations links https://donate.apache.org/ (immediate) and 
> http://apache.org/foundation/contributing.html (will be updated later today)
> 
> Thank you in advance for all your help and incredible support!
> 
> Kind regards,
> Sally
>  
> = = = = = 
> vox +1 617 921 8656
> gvox +1 646 598 4616
> skype sallykhudairi
> 
> 
> From: Sally Khudairi 
> To: ASF Marketing & Publicity ; ASF Fundraising 
>  
> Sent: Sunday, March 26, 2017 7:14 PM
> Subject: Re: [PMCs] Seeking your help for ASF's 18th Anniversary
> 
> Hello PMCs --a heads-up that our launch tomorrow has been postponed due to an 
> outstanding issue with one of our payment processing systems.
> 
> We are working on the issue and are hoping to announce at 6AM ET on Tuesday 
> 28 March. Fingers crossed.
> 
> I'll confirm once we're live. We appreciate your patience!
> 
> Kind thanks,
> Sally
>  
> = = = = = 
> vox +1 617 921 8656
> gvox +1 646 598 4616
> skype sallykhudairi
> 
> 
> From: Sally Khudairi 
> To: ASF Marketing & Publicity ; Apache Software Foundation 
>  
> Sent: Friday, March 24, 2017 4:10 PM
> Subject: [PMCs] Seeking your help for ASF's 18th Anniversary
> 
> Hello Apache PMCs (in blindcopy) --I trust you are well. 
> 
> I wanted to give you a heads-up that at 6AM ET this Monday, 27 March, we will 
> be issuing a press release announcing the ASF's 18th Anniversary. This will 
> be posted across the ASF's usual communication channels (blogs.apache.org, 
> annou...@apache.org , @TheASF Twitter feed, and 
> ASF LinkedIn page). 
> 
> Many of the achievements highlighted in the press release are a direct result 
> of your efforts :-) 
> 
> Coupled with this announcement is our interest in boosting ASF fundraising 
> efforts in the form of individual donations. We will be launching our new 
> "Support Apache" campaign, and are inviting folks to make a donation of any 
> size (if possible) as a one-time donation or on a recurring basis. 
> 
> To that end, we are asking all PMCs to add the Support Apache logo 
> https://s.apache.org/SupportApache  to 
> your project pages with a link to the campaign when we go live next week. I 
> will confirm the link when we're live.
> 
> Thank you in advance for helping spread the word to your communities. Also, 
> if there are any organizations involved with your projects that may be 
> interested in ASF Sponsorship, we'd love to hear about it. 
> 
> We appreciate all your support in helping us continue to build for our 
> future. 
> 
> Kindest regards, 
> Sally 
> 
> 
> = = = = =  
> vox +1 617 921 8656
> gvox +1 646 598 4616
> skype sallykhudairi
> 
> 
> 
> 

Re: IGNITE - 4760 : working in hibernate module

[Вадим Опольский]

Denis, thank you for instruction.

I've successfully applied it:

1) cloned project by my fork - https://github.com/vadopolski/ignite
2) created project from existing sources
3) built it - mvn clean package -DskipTests -Prelease,lgpl
4) created module from existing sources (import module from external model)

Vadim Opolski

2017-03-27 18:20 GMT+03:00 Denis Magda :

> Vadim,
>
> What IDE do you use? My recommendation would be to set up everything let’s
> say under IntellijIDEA or Eclipse and after that trying to compile from a
> terminal.
>
> This is how you can easily prepare the dev env in IntellijIDEA:
> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup <
> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup>
>
> —
> Denis
>
> > On Mar 27, 2017, at 7:14 AM, Вадим Опольский 
> wrote:
> >
> > Valentin, OK.
> >
> > To enabled it in my environment I done next:
> > - built project with command - mvn clean package -DskipTests
> -Prelease,lgpl
> > - added folder hibernate to modules in project structure
> > - added library to dependencies (without it import doesn't working)
> >
> > After that I have a lot of error, for instance:
> > - Class 'AccessStrategy' must either be declared abstract or implement
> abstract method 'remove(SharedSessionContractImplementor, Object) in
> 'RegionAccessStrategy'
> >
> > generateCacheKey
> > getCacheKeyId
> > getRegion
> > insert
> > afterInsert
> > update
> > afterUpdate
> > insert
> > afterInsert
> > update
> > get
> > putFromLoad
> > lockItem
> > unlockItem
> > remove
> >
> > Do anybody know the easier way to resolve this issue?
> >
> > Also tried to reimport all maven projects and cleansed repository in .m2.
> > Vadim Opolski
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2017-03-25 2:42 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com >:
> > Vadim,
> >
> > ignite-hibernate module is a part of 'lgpl' profile. Apparently it's not
> > enabled in your environment.
> >
> > -Val
> >
> > On Fri, Mar 24, 2017 at 4:38 PM, Вадим Опольский  >
> > wrote:
> >
> > > Hello everybody,
> > >
> > > I want to resolve issue №4760
> > > https://issues.apache.org/jira/browse/IGNITE-4760 <
> https://issues.apache.org/jira/browse/IGNITE-4760>
> > >
> > > To find solution I'm going to change method threadLocalForCache and to
> add
> > > Junit test.
> > >
> > > Why folder hibernate is not a module ? Can I added it ?
> > >
> > > Vadim Opolski
> > >
> >
>
>

Re: Making News page more visible

[Tom Diederich]

Looks much better! Thanks for making that change.

I've just joined the Apache Ignite community. Most of my career has been
devoted to building and growing technical online communities. I'd be honored
to help the Apache Ignite community grow via some modest social promotion,
blogging -- anywhere I can be of service. So I'll be keeping my eyes open
for suggestions, too, and also making some recommendations from time to
time. 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Making-News-page-more-visible-tp15763p15846.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

Hi, Igniters! I 've made implementation of transactions of non-single
coordinator. Here you can start transaction in one thread and commit it in
another thread.
Take a look on it. Give your thoughts on it.

https://github.com/voipp/ignite/pull/10/commits/3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45

пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin :

> You know better, go ahead! :)
>
> Sergi
>
> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > we've discovered several problems regarding your "accumulation"
> > approach.These are
> >
> >1. perfomance issues when transfering data from temporary cache to
> >permanent one. Keep in mind big deal of concurent transactions in
> > Service
> >commiter
> >2. extreme memory load when keeping temporary cache in memory
> >3. As long as user is not acquainted with ignite, working with cache
> >must be transparent for him. Keep this in mind. User's node can
> evaluate
> >logic with no transaction at all, so we should deal with both types of
> >execution flow : transactional and non-transactional.Another one
> > problem is
> >transaction id support at the user node. We would have handled all
> this
> >issues and many more.
> >4. we cannot pessimistically lock entity.
> >
> > As a result, we decided to move on building distributed transaction. We
> put
> > aside your "accumulation" approach until we realize how to solve
> > difficulties above .
> >
> > чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin :
> >
> > > The problem "How to run millions of entities, and millions of
> operations
> > on
> > > a single Pentium3" is out of scope here. Do the math, plan capacity
> > > reasonably.
> > >
> > > Sergi
> > >
> > > 2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > hmm, If we have millions of entities, and millions of operations,
> would
> > > not
> > > > this approache lead to memory overflow and perfomance degradation
> > > >
> > > > чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > > >
> > > > > 1. Actually you have to check versions on all the values you have
> > read
> > > > > during the tx.
> > > > >
> > > > > For example if we have [k1 => v1, k2 => v2] and do:
> > > > >
> > > > > put(k1, get(k2) + 5)
> > > > >
> > > > > We have to remember the version for k2. This logic can be
> relatively
> > > > easily
> > > > > encapsulated in a framework atop of Ignite. You need to implement
> one
> > > to
> > > > > make all this stuff usable.
> > > > >
> > > > > 2. I suggest to avoid any locking here, because you easily will end
> > up
> > > > with
> > > > > deadlocks. If you do not have too frequent updates for your keys,
> > > > > optimistic approach will work just fine.
> > > > >
> > > > > Theoretically in the Committer Service you can start a thread for
> the
> > > > > lifetime of the whole distributed transaction, take a lock on the
> key
> > > > using
> > > > > IgniteCache.lock(K key) before executing any Services, wait for all
> > the
> > > > > services to complete, execute optimistic commit in the same thread
> > > while
> > > > > keeping this lock and then release it. Notice that all the Ignite
> > > > > transactions inside of all Services must be optimistic here to be
> > able
> > > to
> > > > > read this locked key.
> > > > >
> > > > > But again I do not recommend you using this approach until you
> have a
> > > > > reliable deadlock avoidance scheme.
> > > > >
> > > > > Sergi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > Yeah, now i got it.
> > > > > > There are some doubts on this approach
> > > > > > 1) During optimistic commit phase, when you assure no one altered
> > the
> > > > > > original values, you must check versions of other dependent keys.
> > How
> > > > > could
> > > > > > we obtain those keys(in an automative manner, of course) ?
> > > > > > 2) How could we lock a key before some Service A introduce
> changes?
> > > So
> > > > no
> > > > > > other service is allowed to change this key-value?(sort of
> > > pessimistic
> > > > > > blocking)
> > > > > > May be you know some implementations of such approach ?
> > > > > >
> > > > > > ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com
> > > > > >:
> > > > > >
> > > > > > >  Thank you very much for help.  I will answer later.
> > > > > > >
> > > > > > > ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > All the services do not update key in place, but only generate
> > new
> > > > keys
> > > > > > > augmented by otx and store the updated value in the same cache
> +
> > > > > remember
> > > > > > > the keys and versions participating in the transaction in some
> > > > separate
> > > > > > > 

[GitHub] ignite pull request #1628: IGNITE-4826: SQL: Eviction to swap failed if segm...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

Re: IGNITE-4188, savepoints with atomic cache?

[Дмитрий Рябов]

I mean ignore it in savepoints and rollbacks to savepoints becouse
transaction rollbacks already ignore it.

2017-03-28 18:10 GMT+03:00 Yakov Zhdanov :

> Ignore atomicCache.put(k, v) if it is called inside transaction? This is
> very counter intuitive. I am strongly against that.
>
> --Yakov
>

Re: IGNITE-4188, savepoints with atomic cache?

[Yakov Zhdanov]

Ignore atomicCache.put(k, v) if it is called inside transaction? This is
very counter intuitive. I am strongly against that.

--Yakov

Re: IGNITE-4284 - ready for review

[Nikita Amelchev]

Its ok. I doing it for long time because I create branch from master. And I
not saw ignite-4157 where appeared new events.

2017-03-28 16:59 GMT+03:00 Dmitry Karachentsev :

> Hi Nikita,
>
> I've looked through the issue and, because fix is quite small and
> important, committed to PR#1681 [1]. Please take a look at it. Here is the
> code review [2].
> I'll assign it to myself and resolve. If you have any questions about fix,
> please ask.
>
> Thanks for your effort!
>
> [1] https://github.com/apache/ignite/pull/1681
> [2] http://reviews.ignite.apache.org/ignite/review/IGNT-CR-140
>
> -Dmitry.
>
> 22.03.2017 14:41, Nikita Amelchev пишет:
>
> Some about p2p class loading support. I thought that we can unmarshal on
>> processNodeAddFinishedMessage when discovery data recieved. But for
>> unmarshal required optimized marshaller(register classes in sys cache)
>> that
>> starting after joinLatch countdown in this message. I tryed unmarshal
>> filters after joinLatch down but it broke some tests such as reconnects
>> and
>> backups. Its possible unmarshal before joinLatch countdown and sys cache
>> was started? Or forbid node to start and throw checked exception?
>>
>> 2017-02-22 12:35 GMT+03:00 Alexey Goncharuk :
>>
>> Nikita,
>>>
>>> The fix looks wrong to me. The point of the assertion was to ensure an
>>> invariant,
>>> see org.apache.ignite.internal.processors.cache.query.continuous.
>>> CacheContinuousQueryManager#executeQuery
>>> -V2 handler is created only when remote filter factory is not null.
>>>
>>> The test observes both fields equal to null because deserialization
>>> failed
>>> because peer class loading is not supported in certain places of code in
>>> Ignite (namely, discovery subsystem), and joining node receives
>>> registered
>>> continuous queries through discovery data. Silent ignorance of this
>>> failure
>>> is wrong, we should either forbid such a node to start or support p2p
>>> class
>>> loading for discovery (or suggest yet another solution).
>>>
>>> 2017-02-22 12:03 GMT+03:00 Nikita Amelchev :
>>>
>>> Hello. I fixed it.

 Please, review.

 https://issues.apache.org/jira/browse/IGNITE-4284 - Failed second
 client
 node join with continuous query and peer class loading enabled

 latest ci.tests:
 http://ci.ignite.apache.org/project.html?projectId=IgniteTests_
 IgniteTests=pull%2F1564%2Fhead


 --
 Best wishes,
 Amelchev Nikita


>>
>>
>


-- 
Best wishes,
Amelchev Nikita

Re: IGNITE-4284 - ready for review

[Dmitry Karachentsev]

Hi Nikita,

I've looked through the issue and, because fix is quite small and 
important, committed to PR#1681 [1]. Please take a look at it. Here is 
the code review [2].
I'll assign it to myself and resolve. If you have any questions about 
fix, please ask.


Thanks for your effort!

[1] https://github.com/apache/ignite/pull/1681
[2] http://reviews.ignite.apache.org/ignite/review/IGNT-CR-140

-Dmitry.

22.03.2017 14:41, Nikita Amelchev пишет:

Some about p2p class loading support. I thought that we can unmarshal on
processNodeAddFinishedMessage when discovery data recieved. But for
unmarshal required optimized marshaller(register classes in sys cache) that
starting after joinLatch countdown in this message. I tryed unmarshal
filters after joinLatch down but it broke some tests such as reconnects and
backups. Its possible unmarshal before joinLatch countdown and sys cache
was started? Or forbid node to start and throw checked exception?

2017-02-22 12:35 GMT+03:00 Alexey Goncharuk :


Nikita,

The fix looks wrong to me. The point of the assertion was to ensure an
invariant,
see org.apache.ignite.internal.processors.cache.query.continuous.
CacheContinuousQueryManager#executeQuery
-V2 handler is created only when remote filter factory is not null.

The test observes both fields equal to null because deserialization failed
because peer class loading is not supported in certain places of code in
Ignite (namely, discovery subsystem), and joining node receives registered
continuous queries through discovery data. Silent ignorance of this failure
is wrong, we should either forbid such a node to start or support p2p class
loading for discovery (or suggest yet another solution).

2017-02-22 12:03 GMT+03:00 Nikita Amelchev :


Hello. I fixed it.

Please, review.

https://issues.apache.org/jira/browse/IGNITE-4284 - Failed second client
node join with continuous query and peer class loading enabled

latest ci.tests:
http://ci.ignite.apache.org/project.html?projectId=IgniteTests_
IgniteTests=pull%2F1564%2Fhead


--
Best wishes,
Amelchev Nikita

Re: Logging ignite-log4j.jar

[Andrey Mashenkov]

IGNITE-4863 [1] is ready for review.

Fix prevents RootLogger (log4j-1.x) log level from being changed if it can
have negative affect other loggers.

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

[GitHub] ignite pull request #1687: IGNITE-4863: Log4jLogger can change RootLogger lo...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4863: Log4jLogger can change RootLogger logging level unexpectedly.

…n other loggers.

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

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

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

https://github.com/apache/ignite/pull/1687.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 #1687


commit dedbdfaa1c34890484ff184d77612716fb340ff1
Author: Andrey V. Mashenkov 
Date:   2017-03-28T13:22:57Z

Disallow change RootLogger log-level if it can have negative effect on 
other loggers.




---
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.
---

[GitHub] ignite pull request #1686: IGNITE-4669 .NET: Sort binary object fields

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4669 .NET: Sort binary object fields



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

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

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

https://github.com/apache/ignite/pull/1686.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 #1686


commit dc97127537dcaa2bb1fda0d4d4da98614c18bdfb
Author: Pavel Tupitsyn 
Date:   2017-03-28T13:17:47Z

IGNITE-4669 .NET: Sort binary object fields




---
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.
---

[GitHub] ignite pull request #1685: Ignite 4868

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

Ignite 4868



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

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

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

https://github.com/apache/ignite/pull/1685.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 #1685


commit 59ea1c2fa87ee6a9e09f9bf7afc2b1ec8ff205ac
Author: nikolay_tikhonov 
Date:   2017-03-16T10:43:50Z

Merge remote-tracking branch ignite-1.7.9 into ignite-1.8.5

Conflicts:

modules/core/src/test/java/org/apache/ignite/testsuites/IgniteKernalSelfTestSuite.java

Merge remote-tracking branch ignite-1.7.9 into ignite-1.8.5

Conflicts:
docs/RELEASE_NOTES.txt
docs/community/RELEASE_NOTES.txt

modules/compatibility/src/test/java/org/gridgain/grid/compatibility/tests/GridCompatibilityAbstractTest.java
modules/core/src/main/resources/gridgain.properties

commit 946419314b567c604a15ae4f9658d89bc350127b
Author: dkarachentsev 
Date:   2017-03-17T11:57:48Z

IGNITE-4473 - Client should re-try connection attempt in case of concurrent 
network failure.

(cherry picked from commit d124004)

commit f4232e9557fca89065f4ee424afab940265e2d1b
Author: oleg-ostanin 
Date:   2017-03-21T12:32:33Z

IGNITE-4822 Fixed change jvm options for benchmarks

commit 6e2bc4bfb0b200e59c9fc3cf4fcbd408d52acb9c
Author: Igor Sapego 
Date:   2017-03-21T14:51:40Z

IGNITE-4200: Added copying of the C++ binaries.

commit 3aa2a68c02879ec57c46091cd2f22a9ac4b129ad
Author: dkarachentsev 
Date:   2017-03-22T12:22:50Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.8.5

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java

commit 8ac955cda895fb8e47651967ee6c49b06c89b397
Author: Alexander Paschenko 
Date:   2017-03-28T10:00:17Z

IGNITE-4868 Correct handling of JDK Object with binary marshaller




---
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.
---

[GitHub] ignite pull request #1684: IGNITE-4575: fix javadoc

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[GitHub] ignite pull request #1684: IGNITE-4575: fix javadoc

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4575: fix javadoc



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

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

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

https://github.com/apache/ignite/pull/1684.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 #1684


commit e7b14746f734512a3316e2afbd414524b21d4ec1
Author: tledkov-gridgain 
Date:   2017-03-28T12:24:31Z

IGNITE-4575: fix javadoc




---
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.
---

[GitHub] ignite pull request #1683: IGNITE-4575: fix javadoc

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---
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.
---

Re: Please review IGNITE-4838

[Yakov Zhdanov]

Alex, I will try to review this in a couple of days.

--Yakov

[GitHub] ignite pull request #1683: IGNITE-4577: fix javadoc

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4577: fix javadoc



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-fix-cache-javadoc

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

https://github.com/apache/ignite/pull/1683.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 #1683


commit 98afb3721b5fb23210f827dd3e47074ad631361e
Author: tledkov-gridgain 
Date:   2017-03-28T12:13:48Z

IGNITE-4577: fix javadoc




---
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.
---

Re: IgniteMessaging in async mode

[Vladimir Ozerov]

Dmitry,

When you work with distributed system you cannot ignore the fact that it is
distributed. Agree with Valya that we do not need to do anything here, user
should handle this case on his own.

On Tue, Mar 28, 2017 at 2:35 PM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> I'm talking about real case [1]. User actually doesn't care about
> difficulties of connection establishing or if message wasn't sent. But now
> he has to manually resolve such case. Why not to use existing async mode
> here?
>
> -Dmitry.
>
> [1] http://apache-ignite-users.70518.x6.nabble.com/ignite-messag
> ing-disconnection-behaviour-td11218.html#a11418
>
> 24.03.2017 21:10, Valentin Kulichenko пишет:
>
> I believe it can be blocked if connection can't be established (i.e. socket
>> can't be opened within a timeout). But I don't think that it makes much
>> sense to add async support because of this. Also it would be very
>> confusing
>> as actual send is always asynchronous.
>>
>> -Val
>>
>> On Fri, Mar 24, 2017 at 9:10 AM, Dmitriy Setrakyan > >
>> wrote:
>>
>> I am a bit confused. The "send()" method does not wait for any replies,
>>> why
>>> would it block?
>>>
>>> On Fri, Mar 24, 2017 at 2:38 AM, Dmitry Karachentsev <
>>> dkarachent...@gridgain.com> wrote:
>>>
>>> Hi Igniters!

 We have in IgniteMessaging interface async support, and it's used only

>>> for
>>>
 registering/deregistering listeners, not for message sending. But user

>>> may
>>>
 fall into the case, when connection to destination node was lost and

>>> user's
>>>
 thread is blocked on IgniteMessaging.send()/sendOrdered() methods till
 failureDetectionTimeout is up.

 I think, it may be a good idea to support async mode for sending
 messages
 (and probably without creating separate future for each message).

 What do you think?

 Thanks!

 Dmitry.



>

Please review IGNITE-4838

[Alexey Kuznetsov]

Igniters,

https://issues.apache.org/jira/browse/IGNITE-4838
http://reviews.ignite.apache.org/ignite/review/IGNT-CR-136

Yakov, as most expert in Compute Grid, could you take a look?

-- 
Alexey Kuznetsov

Re: IgniteMessaging in async mode

[Dmitry Karachentsev]

I'm talking about real case [1]. User actually doesn't care about 
difficulties of connection establishing or if message wasn't sent. But 
now he has to manually resolve such case. Why not to use existing async 
mode here?


-Dmitry.

[1] 
http://apache-ignite-users.70518.x6.nabble.com/ignite-messaging-disconnection-behaviour-td11218.html#a11418


24.03.2017 21:10, Valentin Kulichenko пишет:

I believe it can be blocked if connection can't be established (i.e. socket
can't be opened within a timeout). But I don't think that it makes much
sense to add async support because of this. Also it would be very confusing
as actual send is always asynchronous.

-Val

On Fri, Mar 24, 2017 at 9:10 AM, Dmitriy Setrakyan 
wrote:


I am a bit confused. The "send()" method does not wait for any replies, why
would it block?

On Fri, Mar 24, 2017 at 2:38 AM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:


Hi Igniters!

We have in IgniteMessaging interface async support, and it's used only

for

registering/deregistering listeners, not for message sending. But user

may

fall into the case, when connection to destination node was lost and

user's

thread is blocked on IgniteMessaging.send()/sendOrdered() methods till
failureDetectionTimeout is up.

I think, it may be a good idea to support async mode for sending messages
(and probably without creating separate future for each message).

What do you think?

Thanks!

Dmitry.

[GitHub] ignite pull request #1682: IGNITE-3939 Compact long zero values binary repre...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3939  Compact long zero values binary representation



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

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

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

https://github.com/apache/ignite/pull/1682.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 #1682


commit 2d5b989b7212b968789048ba739acec0dc0b283c
Author: tledkov-gridgain 
Date:   2017-02-28T12:03:55Z

IGNITE-3939: Binary: use special offset cont as offset for null references

commit d0534ff101448d745ad945e0fa44ff29b8e0cc62
Author: tledkov-gridgain 
Date:   2017-03-14T12:53:26Z

Merge branch 'ignite-2.0' into ignite-3939-null

commit 0bc5c78736a18f7bf944f2139912c3cb3598f412
Author: tledkov-gridgain 
Date:   2017-03-17T13:22:05Z

Merge branch 'ignite-2.0' into ignite-3939-null

commit 3822d82c1617d95a87d50afe33fba4176c1f86f9
Author: tledkov-gridgain 
Date:   2017-03-27T12:49:16Z

Merge branch 'master' into ignite-3939-null

commit 264c86a7c1abb9dc2e25b2803709a5dc47be14b8
Author: tledkov-gridgain 
Date:   2017-03-27T13:25:00Z

IGNITE-3939: save the progress

commit 30cd32409f838605fd8acee731ef44b99180ff25
Author: tledkov-gridgain 
Date:   2017-03-27T14:53:58Z

IGNITE-3939: save the progress

commit 72debc5ac23cf7fa5f98aa36e094f98c5ee56ce3
Author: tledkov-gridgain 
Date:   2017-03-27T14:55:25Z

Merge branch 'master' into ignite-3939-null

commit f50ee1c1a6ba4ada09ca3a030111e7fd8b83
Author: tledkov-gridgain 
Date:   2017-03-27T15:27:25Z

IGNITE-3939: save the progress

commit aa71e39c84327e34b4b072a96d11b1f037ee1f27
Author: tledkov-gridgain 
Date:   2017-03-28T09:06:13Z

Merge branch 'master' into ignite-3939-null

commit 5739b800ed178c0042a31ea53896aaf0a419045c
Author: tledkov-gridgain 
Date:   2017-03-28T11:25:43Z

IGNITE-3939: fix null inside the instance of the BinaryValueWithType




---
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-4874) SQL engine should throw meaningful exception on query from local cache

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-4874:
-

 Summary: SQL engine should throw meaningful exception on query 
from local cache
 Key: IGNITE-4874
 URL: https://issues.apache.org/jira/browse/IGNITE-4874
 Project: Ignite
  Issue Type: Task
  Components: SQL
Affects Versions: 2.0
Reporter: Vasiliy Sisko
Priority: Minor


To reproduce:
Configure local cache
Configure partitioned cache
Extract data from local cache by sending query to partitioned cache.

Got error on iteration of received result Cursor:
{code}
java.lang.AssertionError: GridCacheAdapter 
[locMxBean=org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@492168ef,
 
clusterMxBean=org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl@70abe2fc,
 
aff=org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl@510d8baf,
 igfsDataCache=false, mongoDataCache=false, mongoMetaCache=false, 
igfsDataCacheSize=null, igfsDataSpaceMax=0, 
asyncOpsSem=java.util.concurrent.Semaphore@7938449a[Permits = 500], 
name=c_local, size=77]
at 
org.apache.ignite.internal.processors.cache.GridCacheContext.topology(GridCacheContext.java:828)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.hasMovingPartitions(GridReduceQueryExecutor.java:391)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:378)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:517)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1149)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: IGNITE-4188, savepoints with atomic cache?

[Yakov Zhdanov]

As far as I know operations on atomic caches are applied immediately
dishonoring any tx context.

I would suggest that atomic cache update operation called from active tx
throws illegal state exception, unless user intentionally permits this
update by calling atomicCache.withAllowInTx() (similar to withSkipStore()).

Thoughts?

--Yakov

IGNITE-4188, savepoints with atomic cache?

[Дмитрий Рябов]

Hello, community. How should savepoint and rollback to savepoint react to
the atomic caches inside transaction? I think they should ignore such
entries, but I want to know opinion of more competent igniters.

https://issues.apache.org/jira/browse/IGNITE-4188

[GitHub] ignite pull request #1267: IGNITE-4284 - Test

[dkarachentsev]

Github user dkarachentsev closed the pull request at:

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


---
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-4873) Web console: Improve log when agent try to connect to not Ignite node.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-4873:
-

 Summary: Web console: Improve log when agent try to connect to not 
Ignite node.
 Key: IGNITE-4873
 URL: https://issues.apache.org/jira/browse/IGNITE-4873
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 2.0
Reporter: Vasiliy Sisko


When port is used by another process Web console show not informative message 
about connection failure. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1680: IGNITE-3487: Made _key and _val columns hidden

[skalashnikov]

GitHub user skalashnikov opened a pull request:

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

IGNITE-3487:  Made _key and _val columns hidden



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

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

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

https://github.com/apache/ignite/pull/1680.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 #1680


commit 8946b312670b0721c3dc271c12933c80c41668ed
Author: skalashnikov 
Date:   2017-03-17T17:57:19Z

IGNITE-3487: Made _key and _val columns hidden

commit 10ba37183806712994ff193af886d9744da3edc1
Author: skalashnikov 
Date:   2017-03-20T09:25:39Z

IGNITE-3487: minor fixes

commit 603fe292b27ddc421d42eb9156f03b77dc1c5233
Author: skalashnikov 
Date:   2017-03-28T08:53:25Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-3487




---
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-4872) GridQueryIndexing.registerType should return void

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4872:
---

 Summary: GridQueryIndexing.registerType should return void
 Key: IGNITE-4872
 URL: https://issues.apache.org/jira/browse/IGNITE-4872
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.0


No need to maintain {{registered}} semantics as it is not used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Continuations for services

[Vladimir Ozerov]

Valya,

Could you please point me where we delegate thread to another pool? I
remember we did something around this when working with some streamer
problems.

On Tue, Mar 28, 2017 at 4:18 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Vova,
>
> Agree, I already merged IGNITE-4802.
>
> However, I'm still interested why we always switch to another thread when
> executing a job locally. Does anyone have an idea why we do this?
>
> -Val
>
> On Sat, Mar 25, 2017 at 7:22 AM, Vladimir Ozerov 
> wrote:
>
> > Valya,
> >
> > I don't think it will resolve all the cases. For example, what if I
> execute
> > remote job from another job? "Remoteness" could be caused by job natire
> > (broadcast), specific cluster group, or affinity call/run on remote key.
> > Also starvation is possible not only on local node, but between nodes,
> and
> > in this case separate pool is the only reliable solution.
> >
> > On Sat, Mar 25, 2017 at 1:50 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Folks,
> > >
> > > I tend to think that a separate pool for services is not right
> solution.
> > >
> > > We currently execute any new compute job in a separate thread, even if
> > > we're already in the public pool (see code in
> > > GridJobProcessor#processJobExecuteRequest). What is the reason for
> this?
> > > When a job synchronously executes another job on the same node, can we
> > just
> > > execute it in the same thread? This seems to fix all starvation issues
> > > discussed in this thread.
> > >
> > > Am I missing something?
> > >
> > > -Val
> > >
> > > On Thu, Mar 9, 2017 at 2:32 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > OK, I created it: https://issues.apache.org/jira/browse/IGNITE-4802
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 9, 2017 at 9:58 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > >> Valya,
> > > >>
> > > >> Not yet.
> > > >>
> > > >> On Thu, Mar 9, 2017 at 11:50 AM, Valentin Kulichenko <
> > > >> valentin.kuliche...@gmail.com> wrote:
> > > >>
> > > >> > Vladimir,
> > > >> >
> > > >> > This makes sense to me. Is there a ticket for separate thread pool
> > for
> > > >> > services?
> > > >> >
> > > >> > -Val
> > > >> >
> > > >> > On Thu, Mar 9, 2017 at 2:52 AM, Dmitriy Setrakyan <
> > > >> dsetrak...@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> > > Vladimr, it sounds like what you are suggesting is allowing
> users
> > > >> specify
> > > >> > > named executors in configuration and then use them from code,
> > > right? I
> > > >> > > think I like this idea very much.
> > > >> > >
> > > >> > > On Wed, Mar 8, 2017 at 1:46 PM, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > >> >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Continuations is not very good idea. It is useful if user has
> > > simple
> > > >> > > logic
> > > >> > > > when one job calls another from within the same
> execute/run/call
> > > >> > method.
> > > >> > > > But if you have complex logic with OOP abstractions and
> reusable
> > > >> > > > components, nested job call can be located many stack frames
> > down
> > > >> from
> > > >> > > > parent job. In this case continuations are unusable.
> > > >> > > >
> > > >> > > > More convenient approach is to map separate jobs to separate
> > > thread
> > > >> > > pools.
> > > >> > > > This technique is successfully employed in Hazelcast. You just
> > > >> define
> > > >> > > > additional executors and say that job A is to be executed one
> > > thread
> > > >> > > pool,
> > > >> > > > and job B on another.
> > > >> > > >
> > > >> > > > The same technique is applicable for services:
> > > >> > > >
> > > >> > > > class MyService implements Service {
> > > >> > > > @IgniteInstanceResource
> > > >> > > > Ignite ignite;
> > > >> > > >
> > > >> > > > void myMethod() {
> > > >> > > >
> > > >> > > > ignite.service().withExecutor("myExecutor").service("
> > > >> > > > myService").nestedCall();
> > > >> > > > }
> > > >> > > > }
> > > >> > > >
> > > >> > > > All in all I would do the following:
> > > >> > > > 1) Create separate built-in pool for services to make sure
> that
> > in
> > > >> > simple
> > > >> > > > cases users are able to call compute jobs from service
> methods.
> > > >> > > > 2) Implement custom executors which will be applicable for
> both
> > > >> compute
> > > >> > > [1]
> > > >> > > > and service components.
> > > >> > > >
> > > >> > > > [1] https://issues.apache.org/jira/browse/IGNITE-4699
> > > >> > > >
> > > >> > > > 08 марта 2017 г. 23:01 пользователь "Dmitriy Setrakyan" <
> > > >> > > > dsetrak...@apache.org> написал:
> > > >> > > >
> > > >> > > > > On Wed, Mar 8, 2017 at 11:58 AM, Valentin Kulichenko <
> > > >> > > > > valentin.kuliche...@gmail.com> wrote:
> > > >> > > > >
> > > >> > > > > > Separate thread pool will not solve the case of calling a
> > > >> service
> > > >> > > from
> > > >> > > > > > another service.
> > > >> > > >