Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

[ALEKSEY KUZNETSOV]

plz review ticket again

чт, 9 мар. 2017 г. в 10:28, ALEKSEY KUZNETSOV :

> plz review ticket again
>
> вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV  >:
>
> plz review ticket again
>
> пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk  >:
>
> Thanks, Aleksey,
>
> I will take a look this week.
>
> --AG
>
> 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Hi! Review my PR again, plz - https://github.com/apache/ignite/pull/1517
> >
> > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> >
> > > thanx! my next PR review will be in up source
> > >
> > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > Aleksey,
> > >
> > > I added a comment on GitHub, however, the community is moving towards
> the
> > > UpSource review tool, so I suggest you open a PR review in Ignite
> > UpSource:
> > > http://reviews.ignite.apache.org/ignite/
> > >
> > > After you've registered, you should be able to open a review.
> > >
> > > --AG
> > >
> > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Again, plz, review my PR :
> https://github.com/apache/ignite/pull/1517
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

[Vyacheslav Daradur]

Hello everyone.

Please review changes. https://issues.apache.org/jira/browse/IGNITE-4804

I found this mistake when I worked on an another issue.
I created new issue (ignite-4804), because reviewer told me I should fix
this in different task, because it didn't relates to that issue.

Re: Request adding to contributors list

[kartik somani]

Hi Alexey,

My ID is kay_jpr.

Thanks & Regards,
Kartik

On Fri, Mar 10, 2017 at 6:33 AM, Alexey Kuznetsov 
wrote:

> Hi, Kartik!
>
> What is your Apache JIRA ID?
>
> On Fri, Mar 10, 2017 at 2:38 AM, Kartik Somani <
> kartiksomani.offic...@gmail.com> wrote:
>
> > Hi,
> >
> > Can someone add me to contributors list?
> >
> > I want to assign a ticket to myself, but unable to.
> >
> > Regards,
> > Kartik
> >
>
>
>
> --
> Alexey Kuznetsov
>

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

[ALEKSEY KUZNETSOV]

Hi! Can u plz review ticket once more

вт, 7 мар. 2017 г. в 18:52, Andrey Gura :

> Aleksey, thanks a lot!
>
> Answered in JIRA ticket.
>
> On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV
>  wrote:
> > Hi! I have fixed all sources. Plz, review it again
> >
> > пн, 6 мар. 2017 г. в 15:43, Andrey Gura :
> >
> >> Aleksey, thanks!
> >>
> >> I answered in JIRA ticket.
> >>
> >> On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
> >>  wrote:
> >> > I've fixed the comments.
> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> >> >
> >> > пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
> >> >
> >> >> Aleksey,
> >> >>
> >> >> GitHub isn't official review tool in Apache Ignite community. There
> >> >> are two ways for code review: upsource and comments in JIRA tickets.
> >> >> So, I think, we should finish review of this ticket in upsource.
> >> >>
> >> >> On Thu, Mar 2, 2017 at 11:30 AM, ALEKSEY KUZNETSOV
> >> >>  wrote:
> >> >> > lets review code at github rather than upsource later on. Because,
> the
> >> >> > later is too slow and bring no substantial benefits compared github
> >> >> >
> >> >> > ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
> >> >> >
> >> >> >> Hi, Aleksey!
> >> >> >>
> >> >> >> Thank you for contribution!
> >> >> >>
> >> >> >> I've reviewed your changes and have some comments (mostly
> cosmetic).
> >> >> >> Could you please fix this comment? See review in Upsource for
> >> details.
> >> >> >>
> >> >> >> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
> >> >> >>  wrote:
> >> >> >> > Plz, review my PR :
> >> >> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> >> >> >> > or https://github.com/apache/ignite/pull/1545
> >> >> >> > --
> >> >> >> >
> >> >> >> > *Best Regards,*
> >> >> >> >
> >> >> >> > *Kuznetsov Aleksey*
> >> >> >>
> >> >> > --
> >> >> >
> >> >> > *Best Regards,*
> >> >> >
> >> >> > *Kuznetsov Aleksey*
> >> >>
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: general question

[Alexey Goncharuk]

As for the multi-jvm tests, please see isMultiJvm() method and it's
overrides in GridAbstractTest. We have some basic functionality to support
that kind of tests.

--AG

2017-03-09 20:09 GMT+03:00 ALEKSEY KUZNETSOV :

> Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
> multiple ignite instances deployed on different jvms ? If yes, how can i
> create them and address them in code ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: general question

[Alexey Goncharuk]

Hi Aleksey,

In order to ensure that a transaction is rolled back during a node failure,
you need to orchestrate messages in such a way that at least one
participating node does not receive a prepare request. As an example, you
can look
at 
org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCachePrimaryNodeFailureRecoveryAbstractTest.

--AG

2017-03-09 20:09 GMT+03:00 ALEKSEY KUZNETSOV :

> Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
> multiple ignite instances deployed on different jvms ? If yes, how can i
> create them and address them in code ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: IGNITE-2741 - spring session design

[Rishi Yagnik]

Hi Val,

Did you chance to look into session handling issue ?

Thanks,

On Mon, Mar 6, 2017 at 3:37 PM, Rishi Yagnik  wrote:

> Hi Val,
>
> Do you think I can test a fix in 1.9 RC releases ? How are you planning to
> release a fix ?
>
> Did you also look into problem where storing xsrf token in Ignite returns
> an exception and does not behave as expected ?
>
> In SecurityConfig.java use HttpSessionCsrfTokenRepository with following
> code -
>
> .csrfTokenRepository(csrfTokenRepository())
>
> private CsrfTokenRepository csrfTokenRepository() {
> HttpSessionCsrfTokenRepository repository = new 
> HttpSessionCsrfTokenRepository();
> repository.setHeaderName("X-XSRF-TOKEN");
> return repository;
> }
>
> Thank you for all your help,
>
>
> On Mon, Mar 6, 2017 at 2:34 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi Rishi,
>>
>> I got to the bottom of it. Basically, the session is replaced in Spring
>> filter, but caching happens based on the old version which doesn't have
>> security attributes. The fix is going to be very easy, I will do it
>> tomorrow.
>>
>> -Val
>>
>> On Mon, Mar 6, 2017 at 7:34 PM, Rishi Yagnik 
>> wrote:
>>
>> > Val,
>> >
>> > Did you get chance to play around with the code ?
>> >
>> > Thanks,
>> >
>> > On Sun, Mar 5, 2017 at 7:25 PM, Rishi Yagnik 
>> > wrote:
>> >
>> > > Val,
>> > >
>> > > Adding a filter before csrf filter will invoke the custom ignite
>> filter.
>> > >
>> > > Declare a custom filter class extends it with websession filter
>> > >
>> > > public class CustomWebSessionFilter extends WebSessionFilter {
>> > >
>> > >  private static boolean igniteInitialize = false
>> > >
>> > > @Override public void doFilter(ServletRequest req, ServletResponse
>> res,
>> > > FilterChain chain)
>> > > throws IOException, ServletException {
>> > > if(!igniteInitialize) {
>> > > super.init(new FilterConfig() {
>> > > @Override
>> > > public String getFilterName() {
>> > > return "CustomWebSessionFilter";
>> > > }
>> > >
>> > > @Override
>> > > public ServletContext getServletContext() {
>> > > return req.getServletContext();
>> > > }
>> > >
>> > > @Override
>> > > public String getInitParameter(String name) {
>> > > return null;
>> > > }
>> > >
>> > > @Override
>> > > public Enumeration getInitParameterNames() {
>> > > return null;
>> > > }
>> > > });
>> > > igniteInitialize = true;
>> > > }
>> > > super.doFilter(req,res,chain);
>> > > }
>> > > }
>> > >
>> > > And in SecurityConfig.java add following line to invoke filter before
>> > > Ignite Web Session filter -
>> > >
>> > >  .addFilterBefore(new ArWebSessionFilter(), CsrfFilter.class)
>> > >
>> > > Hope it helps..
>> > >
>> > > Thanks,
>> > >
>> > > On Sun, Mar 5, 2017 at 1:28 PM, Valentin Kulichenko <
>> > > valentin.kuliche...@gmail.com> wrote:
>> > >
>> > >> Rishi,
>> > >>
>> > >> Can you please share how you forced Ignite filter to be invoked
>> before
>> > >> security filter?
>> > >>
>> > >> -Val
>> > >>
>> > >> On Sun, Mar 5, 2017 at 11:20 AM, Rishi Yagnik > >
>> > >> wrote:
>> > >>
>> > >> > Hi Val,
>> > >> >
>> > >> > Thanks for the response, we have executed ignite filter before
>> spring
>> > >> > security filter but somehow the ignite filter does not do the job
>> of
>> > >> > setting spring principle context.
>> > >> >
>> > >> > As a result even though we have spring principle in session, spring
>> > >> filter
>> > >> > does not recognize it and sends us back to log in page.
>> > >> >
>> > >> > I think there s some more work needed here to change the filter and
>> > make
>> > >> > it work with spring boot application.
>> > >> >
>> > >> > Take Care,
>> > >> > Rishi
>> > >> >
>> > >> > > On Mar 5, 2017, at 10:16 AM, Valentin Kulichenko <
>> > >> > valentin.kuliche...@gmail.com> wrote:
>> > >> > >
>> > >> > > Hi Rishi,
>> > >> > >
>> > >> > > I did some debugging. Apparently, the reason for this behavior is
>> > that
>> > >> > > Spring Security filter resides before Ignite's filter in the
>> chain
>> > >> list.
>> > >> > I
>> > >> > > think that eventually this should be fixed in the product, but in
>> > the
>> > >> > > meantime there must be a way to work around the problem by
>> > controlling
>> > >> > the
>> > >> > > order. Do you know how this can be done in Spring Boot?
>> > >> > >
>> > >> > > -Val
>> > >> > >
>> > >> > >> On Tue, Feb 28, 2017 at 9:31 AM, Rishi Yagnik <
>> > rishiyag...@gmail.com
>> > >> >
>> > >> > wrote:
>> > >> > >>
>> > >> > >> Hi Val,
>> > >> > >>
>> > >> > >> Sorry for pestering, thanks for all your help.
>> > >> > >>
>> > >> > >> Rishi
>> > >> > >>
>> > >> > >> On Mon, Feb 27, 2017 at 7:22 PM, Valentin Kulichenko <
>> 

Re: Request adding to contributors list

[Alexey Kuznetsov]

Hi, Kartik!

What is your Apache JIRA ID?

On Fri, Mar 10, 2017 at 2:38 AM, Kartik Somani <
kartiksomani.offic...@gmail.com> wrote:

> Hi,
>
> Can someone add me to contributors list?
>
> I want to assign a ticket to myself, but unable to.
>
> Regards,
> Kartik
>



-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-4809) Cache.getAll can return partially commited results.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4809:


 Summary: Cache.getAll can return partially commited results.
 Key: IGNITE-4809
 URL: https://issues.apache.org/jira/browse/IGNITE-4809
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Andrew Mashenkov


1. Create tansactional cache with Long values and fill it with zeroes.
2. Start thread that would increment all values in single transaction.
3. Start thread that would check all values are same in single transaction.

Second thread will see partial commits, but shouldn't.




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

Re: Merging all network components to a single one

[Dmitriy Setrakyan]

To my understanding, Yakov is suggesting that we simply have one very low
level SPI - let's call it IgniteTcpSpi and current implementations of
discovery and communication will be removed from SPI layer and will
register callbacks with this new SPI.

I think this is too big of a change to try to squeeze it into 2.0 release.

Yakov, what are your thoughts.

On Thu, Mar 9, 2017 at 10:30 AM, Denis Magda  wrote:

> Yakov,
>
> However an end user still will be able to provide its own implementation
> for this combiner discovery & communication layers, right?
> Just want to be sure that if I want to add some custom RDMA, RoCe or
> InfiniBand implementation then I’ll be able to do this.
>
> —
> Denis
>
> > On Mar 9, 2017, at 1:11 AM, Yakov Zhdanov  wrote:
> >
> > Dmitry, yes, your understanding is correct.
> >
> > Denis, I remember I already shared the idea a while ago, but completely
> > forgot about the ticket. Thanks for bringing it up! You should give me
> > couple of tips on how to use "Search" function in Jira :)
> >
> > Guys, this will be compatibility breaking change, as there will be no,
> for
> > example, discovery and communication SPIs. What if we move current
> > implementations to internal packages, introduce configuration
> > properties/beans so we can release and continue development in 2.0
> without
> > breaking compatibility?
> >
> > --Yakov
>
>

Apache Ignite SQL Grid Webinar

[Denis Magda]

Igniters,

Let me invite you to join the next Apache Ignite webinar that will be fully 
dedicated to SQL Grid component:
https://www.gridgain.com/company/news/events/gridgain-webinar-apacher-ignitetm-sql-grid-hot-blend-traditional-sql-and-memory
 


This will be a technical deep dive with a mixture of theory and nice demos. So, 
don’t miss your chance to attend and ask tricky questions you might have ;)

—
Denis

Request adding to contributors list

[Kartik Somani]

Hi,

Can someone add me to contributors list?

I want to assign a ticket to myself, but unable to.

Regards,
Kartik

Re: Merging all network components to a single one

[Denis Magda]

Yakov,

However an end user still will be able to provide its own implementation for 
this combiner discovery & communication layers, right?
Just want to be sure that if I want to add some custom RDMA, RoCe or InfiniBand 
implementation then I’ll be able to do this.

—
Denis

> On Mar 9, 2017, at 1:11 AM, Yakov Zhdanov  wrote:
> 
> Dmitry, yes, your understanding is correct.
> 
> Denis, I remember I already shared the idea a while ago, but completely
> forgot about the ticket. Thanks for bringing it up! You should give me
> couple of tips on how to use "Search" function in Jira :)
> 
> Guys, this will be compatibility breaking change, as there will be no, for
> example, discovery and communication SPIs. What if we move current
> implementations to internal packages, introduce configuration
> properties/beans so we can release and continue development in 2.0 without
> breaking compatibility?
> 
> --Yakov

Re: testing in multi JVM mode

[Denis Magda]

Hi Aleksey,

GridAbstractTest has isMultiJvm() parameter that when set to ‘true’ will 
execute the nodes in separate JVM processes. Refer to the tests that contain 
“MultiJvm” in their names as to examples of usage.

P.S.
Renamed the subject. Please give more specific names to email subjects. There 
are already three different “general question” discussions started on the dev 
list.

—
Denis

> On Mar 9, 2017, at 9:09 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
> multiple ignite instances deployed on different jvms ? If yes, how can i
> create them and address them in code ?
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

[jira] [Created] (IGNITE-4808) Add all Hadoop examples as Ignite unit tests with default multi-JVM execution mode

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-4808:
---

 Summary: Add all Hadoop examples as Ignite unit tests with default 
multi-JVM execution mode
 Key: IGNITE-4808
 URL: https://issues.apache.org/jira/browse/IGNITE-4808
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 2.0
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky


Should have all Hadoop examples as Ignite unit tests with multi-JVM mode being 
the default.




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

general question

[ALEKSEY KUZNETSOV]

Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
multiple ignite instances deployed on different jvms ? If yes, how can i
create them and address them in code ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

general question

[ALEKSEY KUZNETSOV]

Hi all! Consider we've got local transaction. How can i simulate node
breakage in tests so that transaction will be in ROLLED_BACK state?

-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: IgniteConfiguration.gridName is very confusing

[Alexander Fedotov]

Sure. Will take a look.

On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov  wrote:

> Alexander,
>
> Page https://github.com/apache/ignite/pull/1435 reports several conflicts.
> Can you please check and resolve if necessary. Then resubmit for review
> again.
>
> --Yakov
>
> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov  >:
>
> > Hi, it's ready for review
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >
> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov 
> > wrote:
> >
> > > Guys, I want to bring this up. What is the status of this ticket and
> > > further steps?
> > >
> > > --Yakov
> > >
> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> > alexander.fedot...@gmail.com
> > > >:
> > >
> > > > Done. But it looks like something went wrong since Upsource reports:
> > > > "Review has too many files (1244), aborting".
> > > >
> > > > Also guys, I believe we need to merge this change in short time
> because
> > > > it's targeted for 2.0 and chances for a conflict are high.
> > > >
> > > >
> > > >
> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > wrote:
> > > >
> > > > > Alexander,
> > > > >
> > > > > Please name the review appropriately and link it in the ticket as
> > > > > described:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > > > alexander.fedot...@gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Created Upsource review for the subject:
> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > > > >
> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > > > > alexander.fedot...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I've completed working on IGNITE-3207
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > > > > >
> > > > > > > Looks like TC test results don't have problems related to my
> > > changes
> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&;
> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > > > > >
> > > > > > > Kindly take a look at PR https://github.com/apache/
> > > ignite/pull/1435/
> > > > > > >
> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> dma...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > >> Support Pavel’s point of view.
> > > > > > >>
> > > > > > >> Also Alexander please make sure that your changes are merged
> > into
> > > > > > >> ignite-2.0 branch rather than to the master. I think this
> > > > > functionality
> > > > > > >> has to be available in 2.0 first. Finally, please update 2.0
> > > > Migration
> > > > > > >> Guide once you’ve finished with this task:
> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > > > > >> Ignite+2.0+Migration+Guide  > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > > > > >>
> > > > > > >> —
> > > > > > >> Denis
> > > > > > >>
> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > > ptupit...@apache.org
> > > > >
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > I think we should fix log output as well and replace all
> > "grid"
> > > > > > >> occurences
> > > > > > >> > with "instance".
> > > > > > >> >
> > > > > > >> > On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov <
> > > > > > >> > alexander.fedot...@gmail.com> wrote:
> > > > > > >> >
> > > > > > >> >> Hi,
> > > > > > >> >>
> > > > > > >> >> I think we should leave null as a default value for unnamed
> > > > Ignite
> > > > > > >> >> instances. At least that change should be considered out of
> > the
> > > > > > current
> > > > > > >> >> scope.
> > > > > > >> >>
> > > > > > >> >> What about naming, I'm also renaming log occurrences of
> > "grid"
> > > > and
> > > > > > >> "grid
> > > > > > >> >> name" where it stands reasonable.
> > > > > > >> >> Are there places in the logging logic where we should
> prefer
> > > name
> > > > > > >> "grid" or
> > > > > > >> >> "grid name" instead of "Ignite instance name" or "Ignite
> > > instance
> > > > > > >> name" can
> > > > > > >> >> be used without any semantic impact?
> > > > > > >> >>
> > > > > > >> >> On Sat, Dec 31, 2016 at 11:23 AM, Alexander Fedotov <
> > > > > > >> >> alexander.fedot...@gmail.com> wrote:
> > > > > > >> >>
> > > > > > >> >>> Okay. From the all said above I suppose "instanceName"
> > should
> > > > work
> > > > > > for
> > > > > > >> >>> IgniteConfiguration and "igniteInstanceName" in all other
> > > > places.
> > > > > > >> >>>
> > > > > > >> >>> Regards,
> > > > > > >> >>> Alexander
> > > > > > >> >>>
> > > > > > >> >>> 31 дек. 2016 г. 3:43 AM пользователь "Dmitriy Setrakyan" <
> > > > > > >> >>> dsetrak...@apache.org> написал:
> > > > > > >> >>>
> > > > > > >> >>> It sounds like it must be unique then. I wo

Re: IgniteConfiguration.gridName is very confusing

[Yakov Zhdanov]

Alexander,

Page https://github.com/apache/ignite/pull/1435 reports several conflicts.
Can you please check and resolve if necessary. Then resubmit for review
again.

--Yakov

2017-03-03 13:24 GMT+03:00 Alexander Fedotov :

> Hi, it's ready for review
> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>
> On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov 
> wrote:
>
> > Guys, I want to bring this up. What is the status of this ticket and
> > further steps?
> >
> > --Yakov
> >
> > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> alexander.fedot...@gmail.com
> > >:
> >
> > > Done. But it looks like something went wrong since Upsource reports:
> > > "Review has too many files (1244), aborting".
> > >
> > > Also guys, I believe we need to merge this change in short time because
> > > it's targeted for 2.0 and chances for a conflict are high.
> > >
> > >
> > >
> > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn 
> > > wrote:
> > >
> > > > Alexander,
> > > >
> > > > Please name the review appropriately and link it in the ticket as
> > > > described:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > > alexander.fedot...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Created Upsource review for the subject:
> > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > > >
> > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > > > alexander.fedot...@gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've completed working on IGNITE-3207
> > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > > > >
> > > > > > Looks like TC test results don't have problems related to my
> > changes
> > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&;
> > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > > > >
> > > > > > Kindly take a look at PR https://github.com/apache/
> > ignite/pull/1435/
> > > > > >
> > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda 
> > > > wrote:
> > > > > >
> > > > > >> Support Pavel’s point of view.
> > > > > >>
> > > > > >> Also Alexander please make sure that your changes are merged
> into
> > > > > >> ignite-2.0 branch rather than to the master. I think this
> > > > functionality
> > > > > >> has to be available in 2.0 first. Finally, please update 2.0
> > > Migration
> > > > > >> Guide once you’ve finished with this task:
> > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > > > >> Ignite+2.0+Migration+Guide  > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > > > >>
> > > > > >> —
> > > > > >> Denis
> > > > > >>
> > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > I think we should fix log output as well and replace all
> "grid"
> > > > > >> occurences
> > > > > >> > with "instance".
> > > > > >> >
> > > > > >> > On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov <
> > > > > >> > alexander.fedot...@gmail.com> wrote:
> > > > > >> >
> > > > > >> >> Hi,
> > > > > >> >>
> > > > > >> >> I think we should leave null as a default value for unnamed
> > > Ignite
> > > > > >> >> instances. At least that change should be considered out of
> the
> > > > > current
> > > > > >> >> scope.
> > > > > >> >>
> > > > > >> >> What about naming, I'm also renaming log occurrences of
> "grid"
> > > and
> > > > > >> "grid
> > > > > >> >> name" where it stands reasonable.
> > > > > >> >> Are there places in the logging logic where we should prefer
> > name
> > > > > >> "grid" or
> > > > > >> >> "grid name" instead of "Ignite instance name" or "Ignite
> > instance
> > > > > >> name" can
> > > > > >> >> be used without any semantic impact?
> > > > > >> >>
> > > > > >> >> On Sat, Dec 31, 2016 at 11:23 AM, Alexander Fedotov <
> > > > > >> >> alexander.fedot...@gmail.com> wrote:
> > > > > >> >>
> > > > > >> >>> Okay. From the all said above I suppose "instanceName"
> should
> > > work
> > > > > for
> > > > > >> >>> IgniteConfiguration and "igniteInstanceName" in all other
> > > places.
> > > > > >> >>>
> > > > > >> >>> Regards,
> > > > > >> >>> Alexander
> > > > > >> >>>
> > > > > >> >>> 31 дек. 2016 г. 3:43 AM пользователь "Dmitriy Setrakyan" <
> > > > > >> >>> dsetrak...@apache.org> написал:
> > > > > >> >>>
> > > > > >> >>> It sounds like it must be unique then. I would propose the
> > > > > following:
> > > > > >> >>>
> > > > > >> >>>   1. If user defines the instanceName, then we assign it to
> > the
> > > > > node.
> > > > > >> >>>   2. If user does not define the instance name, then we have
> > to
> > > > give
> > > > > >> it
> > > > > >> >>>   some unique value, like node ID or PID.
> > > > > >> >>>
> > > > > >> >>> Will this change be backward compatible, or shoul

[GitHub] ignite pull request #1607: IGNITE-4803

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-4803



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

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

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

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


commit 12c80e1fc04aed2ff441e25bd2c10009182f8ac1
Author: Igor Seliverstov 
Date:   2017-03-07T14:39:51Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit fbee27914256e5623735d33868dcf03bd4f2ac42
Author: sboikov 
Date:   2017-03-07T15:08:43Z

ignite-4779 review

commit b166e9e15a9b8c0a34e940516de42ff2178d86e9
Author: Igor Seliverstov 
Date:   2017-03-09T09:16:35Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit 3359c2e2658613bbcd8d3ac5f8c3665c108b3cef
Author: Igor Seliverstov 
Date:   2017-03-09T10:25:33Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit 31cc12aff8779cf6406ac0e895da2cdb20df39bd
Author: sboikov 
Date:   2017-03-09T11:04:02Z

ignite-4779 Minor.

commit 050f146178febb2b93529430a2af5ee8e1adf309
Author: Igor Seliverstov 
Date:   2017-03-09T12:24:34Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit 1155db09965be9a5f6a09effe62b20dca4e64b51
Author: Igor Seliverstov 
Date:   2017-03-09T13:18:49Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit d7a4f094b69dc49b2a89d0a9e0b7d040e937921c
Author: Igor Seliverstov 
Date:   2017-03-09T13:57:00Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit 806e3c3253a539eebe50703111c23fab90356e18
Author: Igor Seliverstov 
Date:   2017-03-09T14:27:15Z

[IGNITE-4779] Missed discovery data snapshot during exchange processing

commit e737ed021d6f15dcbaee75361aaeb6d504e473dd
Author: Igor Seliverstov 
Date:   2017-03-09T14:59:59Z

[IGNITE-4803] Create a test to check processing doesn't break when 
discovery cache history overflows




---
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: general question

[Valentin Kulichenko]

DHT refers to server side cache. Near cache is a part of distributed cache,
but not a part of DHT.

-Val

On Thu, Mar 9, 2017 at 3:39 PM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:

> Probably, the reasoning for it is that near entries have distributed form,
> i.e. they are kept in sync with the
> changes, but actually, they aren't true DHT entries. So
> GridDistributedCacheEntry is the parent for
> GridNearCacheEntry and GridDhtCacheEntry and reflects the distributed
> common nature
> of its descendants.
>
>
> On Thu, Mar 9, 2017 at 3:00 PM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > it looks strange. Because, DHT = distributed
> >
> > чт, 9 мар. 2017 г. в 14:26, Alexander Fedotov <
> > alexander.fedot...@gmail.com
> > >:
> >
> > > I suppose, GridDistributedCacheEntry contains common logic for Near and
> > DHT
> > > entries, while
> > > GridDhtCacheEntry is it's subclass and contains common logic for DHT
> > > entries.
> > > For more details check the class hierarchy.
> > >
> > > On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com>
> > > wrote:
> > >
> > > > I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they
> > > > must have been of the same logic ?
> > > >
> > > >
> > > > пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov <
> > > > alexander.fedot...@gmail.com
> > > > >:
> > > >
> > > > > Yes, DHT stands for distributed hash table.
> > > > >
> > > > > On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV <
> > > > > alkuznetsov...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thank you so much! And the last one. I cannot find definition of
> > DHT.
> > > > > Does
> > > > > > it stand for distributed ? In contrary to Local
> > > > > >
> > > > > > пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> > > > > > alexander.fedot...@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > Probably, IgniteTxHandler#processDhtTxPrepareRequest is what
> you
> > > are
> > > > > > > looking for.
> > > > > > > Check the data flow from GridDhtTxPrepareRequest#nearWrites
> > > > > > >
> > > > > > > On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Ah, thanks! Which class is responsible for near cache
> > > > > synchronization ?
> > > > > > > >
> > > > > > > > пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov <
> > > > > > > > alexander.fedot...@gmail.com
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > Hi Aleksey,
> > > > > > > > >
> > > > > > > > > Local cache pertains only to the node where it's created
> and
> > no
> > > > > data
> > > > > > is
> > > > > > > > > distributed to
> > > > > > > > > or synchronized with other nodes, while near cache serves
> as
> > a
> > > > > front
> > > > > > > end
> > > > > > > > > for a partitioned cache, storing recently requested data
> > which
> > > is
> > > > > > > > > synchronized when it's changed on
> > > > > > > > > other nodes.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Mar 3, 2017 at 10:39 AM, ALEKSEY KUZNETSOV <
> > > > > > > > > alkuznetsov...@gmail.com
> > > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi all ! What is the difference between local and near
> > > > > transactions
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > *Best Regards,*
> > > > > > > > > >
> > > > > > > > > > *Kuznetsov Aleksey*
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Kind regards,
> > > > > > > > > Alexander.
> > > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > *Best Regards,*
> > > > > > > >
> > > > > > > > *Kuznetsov Aleksey*
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Alexander.
> > > > > > >
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Alexander.
> > > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
>
>
> --
> Kind regards,
> Alexander.
>

Re: PR IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[Yakov Zhdanov]

Alexey, you should understand how caches startup and partition map exchange
work. I would suggest you start couple of nodes in single VM and simply do
step-by-step debug in your IDE.

I don't think you will need to introduce any new message, but I think you
will have to add info to GridDhtPartitionsSingleMessage and
GridDhtPartitionsFullMessage. These messages are being sent via
communication as you described.

Thanks!

--Yakov

Re: general question

[Alexander Fedotov]

Probably, the reasoning for it is that near entries have distributed form,
i.e. they are kept in sync with the
changes, but actually, they aren't true DHT entries. So
GridDistributedCacheEntry is the parent for
GridNearCacheEntry and GridDhtCacheEntry and reflects the distributed
common nature
of its descendants.


On Thu, Mar 9, 2017 at 3:00 PM, ALEKSEY KUZNETSOV 
wrote:

> it looks strange. Because, DHT = distributed
>
> чт, 9 мар. 2017 г. в 14:26, Alexander Fedotov <
> alexander.fedot...@gmail.com
> >:
>
> > I suppose, GridDistributedCacheEntry contains common logic for Near and
> DHT
> > entries, while
> > GridDhtCacheEntry is it's subclass and contains common logic for DHT
> > entries.
> > For more details check the class hierarchy.
> >
> > On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com>
> > wrote:
> >
> > > I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they
> > > must have been of the same logic ?
> > >
> > >
> > > пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov <
> > > alexander.fedot...@gmail.com
> > > >:
> > >
> > > > Yes, DHT stands for distributed hash table.
> > > >
> > > > On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com>
> > > > wrote:
> > > >
> > > > > Thank you so much! And the last one. I cannot find definition of
> DHT.
> > > > Does
> > > > > it stand for distributed ? In contrary to Local
> > > > >
> > > > > пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> > > > > alexander.fedot...@gmail.com
> > > > > >:
> > > > >
> > > > > > Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you
> > are
> > > > > > looking for.
> > > > > > Check the data flow from GridDhtTxPrepareRequest#nearWrites
> > > > > >
> > > > > > On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Ah, thanks! Which class is responsible for near cache
> > > > synchronization ?
> > > > > > >
> > > > > > > пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov <
> > > > > > > alexander.fedot...@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > Hi Aleksey,
> > > > > > > >
> > > > > > > > Local cache pertains only to the node where it's created and
> no
> > > > data
> > > > > is
> > > > > > > > distributed to
> > > > > > > > or synchronized with other nodes, while near cache serves as
> a
> > > > front
> > > > > > end
> > > > > > > > for a partitioned cache, storing recently requested data
> which
> > is
> > > > > > > > synchronized when it's changed on
> > > > > > > > other nodes.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Mar 3, 2017 at 10:39 AM, ALEKSEY KUZNETSOV <
> > > > > > > > alkuznetsov...@gmail.com
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all ! What is the difference between local and near
> > > > transactions
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > *Best Regards,*
> > > > > > > > >
> > > > > > > > > *Kuznetsov Aleksey*
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Kind regards,
> > > > > > > > Alexander.
> > > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > *Best Regards,*
> > > > > > >
> > > > > > > *Kuznetsov Aleksey*
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Alexander.
> > > > > >
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>



-- 
Kind regards,
Alexander.

[GitHub] ignite pull request #1606: IGNITE-4804

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-4804



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

$ git pull https://github.com/daradurvs/ignite ignite-4804

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

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


commit fbfb69aaab46f064ba0005f6d312e199d38c13bc
Author: Vyacheslav Daradur 
Date:   2017-03-09T13:47:44Z

ignite-4804: duplicated properties were removed




---
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-4807) Move inner classes of GridQueryProcessor to top-level if possible

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4807:
---

 Summary: Move inner classes of GridQueryProcessor to top-level if 
possible
 Key: IGNITE-4807
 URL: https://issues.apache.org/jira/browse/IGNITE-4807
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.0


Currently {{GridQueryProcessor}} has overly complex structure of inner classes 
what makes DDL development process harder. Let's move some or all classes to 
top-level.



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

[jira] [Created] (IGNITE-4806) Infinite classLoading discovery process

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-4806:
--

 Summary: Infinite classLoading discovery process
 Key: IGNITE-4806
 URL: https://issues.apache.org/jira/browse/IGNITE-4806
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 1.8
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
Priority: Minor


Hello, i found infinite discovery class loading after very rare usage case.
In a nutshell to reproduce we need to run sequentially 3 different jvm 
instances.
FirstNode instance simple start the grid.
SecondNode connect to grid, initialize custom classLoader, and run 
IgniteCallable (JobA) wrapped into ComputeTask instance.
ThirdNode  connect to grid, initialize custom classLoader, and run two 
IgniteCallable (JobB, jobB2) wrapped into ComputeTask instances.
Finally we can observe JobA has been running in First and Second nodes, JobB  
has been running in First, Second and Third nodes, while jobB2 starts infinite 
class loading. We could see it simply looking into First Node thread dump:
{code}
"pub-#69%grid%" prio=10 tid=0x7f9218015800 nid=0x3de5 runnable 
[0x7f9254176000]
   java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
- locked <0x0007d43ced00> (a java.lang.ClassNotFoundException)
at java.lang.Throwable.(Throwable.java:287)
at java.lang.Exception.(Exception.java:84)
at 
java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
at 
java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
- locked <0x00070c22fd08> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:278)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
- locked <0x00070c0361e0> (a 
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:441)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:278)
at 
org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:444)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:454)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:494)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:982)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}



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

[jira] [Created] (IGNITE-4805) Delete GridQueryIndexType

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4805:
---

 Summary: Delete GridQueryIndexType
 Key: IGNITE-4805
 URL: https://issues.apache.org/jira/browse/IGNITE-4805
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0


This class fully duplicates {{QueryIndexType}}. 



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

[jira] [Created] (IGNITE-4804) Remove duplicated properties in parent-pom

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-4804:
--

 Summary: Remove duplicated properties in parent-pom
 Key: IGNITE-4804
 URL: https://issues.apache.org/jira/browse/IGNITE-4804
 Project: Ignite
  Issue Type: Bug
  Components: build
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Priority: Minor


ignite\parent\pom.xml сontains duplicated properties.

In case of their separate change it can result in not expected behavior.



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

Re: general question

[ALEKSEY KUZNETSOV]

it looks strange. Because, DHT = distributed

чт, 9 мар. 2017 г. в 14:26, Alexander Fedotov :

> I suppose, GridDistributedCacheEntry contains common logic for Near and DHT
> entries, while
> GridDhtCacheEntry is it's subclass and contains common logic for DHT
> entries.
> For more details check the class hierarchy.
>
> On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they
> > must have been of the same logic ?
> >
> >
> > пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov <
> > alexander.fedot...@gmail.com
> > >:
> >
> > > Yes, DHT stands for distributed hash table.
> > >
> > > On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com>
> > > wrote:
> > >
> > > > Thank you so much! And the last one. I cannot find definition of DHT.
> > > Does
> > > > it stand for distributed ? In contrary to Local
> > > >
> > > > пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> > > > alexander.fedot...@gmail.com
> > > > >:
> > > >
> > > > > Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you
> are
> > > > > looking for.
> > > > > Check the data flow from GridDhtTxPrepareRequest#nearWrites
> > > > >
> > > > > On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV <
> > > > > alkuznetsov...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Ah, thanks! Which class is responsible for near cache
> > > synchronization ?
> > > > > >
> > > > > > пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov <
> > > > > > alexander.fedot...@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > Hi Aleksey,
> > > > > > >
> > > > > > > Local cache pertains only to the node where it's created and no
> > > data
> > > > is
> > > > > > > distributed to
> > > > > > > or synchronized with other nodes, while near cache serves as a
> > > front
> > > > > end
> > > > > > > for a partitioned cache, storing recently requested data which
> is
> > > > > > > synchronized when it's changed on
> > > > > > > other nodes.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 3, 2017 at 10:39 AM, ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all ! What is the difference between local and near
> > > transactions
> > > > > > > > --
> > > > > > > >
> > > > > > > > *Best Regards,*
> > > > > > > >
> > > > > > > > *Kuznetsov Aleksey*
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Alexander.
> > > > > > >
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Alexander.
> > > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: general question

[Alexander Fedotov]

I suppose, GridDistributedCacheEntry contains common logic for Near and DHT
entries, while
GridDhtCacheEntry is it's subclass and contains common logic for DHT
entries.
For more details check the class hierarchy.

On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV 
wrote:

> I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they
> must have been of the same logic ?
>
>
> пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov <
> alexander.fedot...@gmail.com
> >:
>
> > Yes, DHT stands for distributed hash table.
> >
> > On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com>
> > wrote:
> >
> > > Thank you so much! And the last one. I cannot find definition of DHT.
> > Does
> > > it stand for distributed ? In contrary to Local
> > >
> > > пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> > > alexander.fedot...@gmail.com
> > > >:
> > >
> > > > Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you are
> > > > looking for.
> > > > Check the data flow from GridDhtTxPrepareRequest#nearWrites
> > > >
> > > > On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com>
> > > > wrote:
> > > >
> > > > > Ah, thanks! Which class is responsible for near cache
> > synchronization ?
> > > > >
> > > > > пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov <
> > > > > alexander.fedot...@gmail.com
> > > > > >:
> > > > >
> > > > > > Hi Aleksey,
> > > > > >
> > > > > > Local cache pertains only to the node where it's created and no
> > data
> > > is
> > > > > > distributed to
> > > > > > or synchronized with other nodes, while near cache serves as a
> > front
> > > > end
> > > > > > for a partitioned cache, storing recently requested data which is
> > > > > > synchronized when it's changed on
> > > > > > other nodes.
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 3, 2017 at 10:39 AM, ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > > > Hi all ! What is the difference between local and near
> > transactions
> > > > > > > --
> > > > > > >
> > > > > > > *Best Regards,*
> > > > > > >
> > > > > > > *Kuznetsov Aleksey*
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Alexander.
> > > > > >
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>



-- 
Kind regards,
Alexander.

Re: IGNITE-13 (ready for review)

[Valentin Kulichenko]

Hi Vadim,

Results are a bit confusing. Any idea why it's better on long string, but
worse on a short string? If that's actually the case, there is no any
reason to make the change and I would just close the ticket.

-Val

On Thu, Mar 9, 2017 at 9:20 AM, Вадим Опольский 
wrote:

> Hello everyone!
>
> Colleagues, take a look please at the results of measuring.
>
> Can I close this ticket ?
>
> Should I add JMH benchmark and unit test to Ignite project ?
>
> Results of measuring
> https://github.com/javaller/mybenchmark/blob/master/out.txt
>
> Benchmark
> https://github.com/javaller/mybenchmark/blob/master/src/
> main/java/org/sample/ExampleTest.java
>
> UTest
> https://github.com/javaller/mybenchmark/blob/master/src/
> main/java/org/sample/BinaryMarshallerSelfTest.java
>
> *results of measuring*
> Benchmark
> (message)  Mode  Cnt
> Score   Error  Units
> LatchBenchmark.binaryHeapOutputStreamDirect
> TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
> LatchBenchmark.binaryHeapOutputStreamDirect
> TestTestTestavgt   5044,934 ± 1,463  ns/op
> LatchBenchmark.binaryHeapOutputStreamDirect
> Test  avgt   5021,254 ± 0,776  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> TestTestTest   avgt   5058,975 ± 1,559  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> Test avgt   5048,506 ± 1,116  ns/op
>
>
> Vadim
>
> 2017-03-06 19:42 GMT+03:00 Вадим Опольский :
>
>> Hello, everybody!
>>
>> Valentin, I've corrected benchmark and received the results:
>>
>> Benchmark
>> (message)  Mode  Cnt
>> Score   Error  Units
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> TestTestTestavgt   5044,934 ± 1,463  ns/op
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> Test  avgt   5021,254 ± 0,776  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> TestTestTest   avgt   5058,975 ± 1,559  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> Test avgt   5048,506 ± 1,116  ns/op
>>
>> https://github.com/javaller/MyBenchmark/blob/master/out_06_03_17_2.txt
>>
>> Whats the next step ?
>>
>>  Do I have to add benchmark to Ignite project ?
>>
>> Vadim Opolskiy
>>
>> 2017-03-03 21:11 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> Hi Vadim,
>>>
>>> What do you mean by "copied benchmarks"? What changed singe previous
>>> iteration and why results are so different?
>>>
>>> As for duplicated loop, you don't need it. BinaryOutputStream allows to
>>> write a value to a particular position (even before already written data).
>>> So you can reserve 4 bytes for length, remember position, calculate length
>>> while encoding and writing bytes, and then write length.
>>>
>>> -Val
>>>
>>> On Fri, Mar 3, 2017 at 12:45 AM, Вадим Опольский 
>>> wrote:
>>>
 Valentin,

 What do you think about duplicated cycle in strToBinaryOutputStream ?

 How to calculate StrLen для outBinaryHeap without this cycle ?

 public class BinaryUtilsNew extends BinaryUtils {

 public static int getStrLen(String val) {
 int strLen = val.length();
 int utfLen = 0;
 int c;

 // Determine length of resulting byte array.




 *for (int cnt = 0; cnt < strLen; cnt++) {c = val.charAt(cnt);  
   if (c >= 0x0001 && c <= 0x007F)*utfLen++;
* else if (c > 0x07FF)*
 utfLen += 3;
 else
 utfLen += 2;
 }

 return utfLen;
 }

 public static void strToUtf8BytesDirect(BinaryOutputStream 
 outBinaryHeap, String val) {

 int strLen = val.length();
 int c, cnt;

 int position = 0;

 outBinaryHeap.unsafeEnsure(1 + 4);

 *   outBinaryHeap.unsafeWriteByte(GridBinaryMarshaller.STRING);
 outBinaryHeap.unsafeWriteInt(getStrLen(val));*



 * for (cnt = 0; cnt < strLen; cnt++) {c = val.charAt(cnt);*
* if (c >= 0x0001 && c <= 0x007F)*
 outBinaryHeap.writeByte((byte) c);
  *   else if (c > 0x07FF) {*
 outBinaryHeap.writeByte((byte)(0xE0 | (c >> 12) & 0x0F));
 outBinaryHeap.writeByte((byte)(0x80 | (c >> 6) & 0x3F));
 outB

[jira] [Created] (IGNITE-4803) Create a test to check processing doesn't break when discovery cache history overflows

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-4803:


 Summary: Create a test to check processing doesn't break when 
discovery cache history overflows
 Key: IGNITE-4803
 URL: https://issues.apache.org/jira/browse/IGNITE-4803
 Project: Ignite
  Issue Type: Test
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov
 Fix For: 2.0






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

Re: Continuations for services

[Valentin Kulichenko]

OK, I created it: https://issues.apache.org/jira/browse/IGNITE-4802

-Val

On Thu, Mar 9, 2017 at 9:58 AM, Vladimir Ozerov 
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  >
> > 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 
> > > 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.
> > > > > >
> > > > >
> > > > > Why not? The caller thread should block.
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-4802) Create separate thread pool for services

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4802:
---

 Summary: Create separate thread pool for services
 Key: IGNITE-4802
 URL: https://issues.apache.org/jira/browse/IGNITE-4802
 Project: Ignite
  Issue Type: Improvement
  Components: managed services
Affects Versions: 1.9
Reporter: Valentin Kulichenko
 Fix For: 2.0


Currently if a service is invoked via service proxy, it will be executed on a 
remote node in its public thread pool. This means that it's unsafe to execute a 
compute job or closure from a service as it can cause starvation.

Need to create a separate pool for services to overcome this limitation.



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

Re: PR IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

[ALEKSEY KUZNETSOV]

Regarding your comment in ticket. Do you mean broken factory node ought to
send notifications to cache nodes through sharedCtx.io().send(...) ?

вт, 7 мар. 2017 г. в 14:23, ALEKSEY KUZNETSOV :

> Regarding your comment in ticket. Do you mean broken factory node ought to
> send notifications to cache nodes through sharedCtx.io().send(...) ?
>
> пт, 3 мар. 2017 г. в 11:33, Yakov Zhdanov :
>
> Alexey, my comments are in the ticket. Please address them.
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2017-03-01 12:15 GMT+03:00 Yakov Zhdanov :
>
> > Alexey, I will take a look at this in couple of days.
> >
> > --Yakov
> >
> > 2017-03-01 11:25 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> >> Plz, review my changes
> >> https://issues.apache.org/jira/browse/IGNITE-1094
> >>
> >> https://github.com/apache/ignite/pull/1581
> >> --
> >>
> >> *Best Regards,*
> >>
> >> *Kuznetsov Aleksey*
> >>
> >
> >
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1605: Ignite 1.7.9

[avinogradovgg]

GitHub user avinogradovgg opened a pull request:

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

Ignite 1.7.9



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

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

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

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


commit 60d27547dfc6bd27c6d39cbcc523d0d1e872a821
Author: vozerov-gridgain 
Date:   2016-10-11T11:51:00Z

Merge remote-tracking branch 'upstream/ignite-1.6.10' into ignite-1.6.10

commit 359a392f1c53217c691c4c40762c51fd330666e2
Author: Valentin Kulichenko 
Date:   2016-01-15T06:58:41Z

Update notifier fixes

(cherry picked from commit a5c85ca)

commit 01ca6db70933fb7f50f161a80cde9647e68a3710
Author: dkarachentsev 
Date:   2016-10-11T13:18:40Z

Merge remote-tracking branch 'origin/ignite-1.6.10' into ignite-1.6.10

commit 0659bebe04dc9c0b0a163bc95061519c553e678c
Author: Andrey V. Mashenkov 
Date:   2016-10-12T11:49:36Z

IGNITE-3972: Fixed a bug causing continuous queries to be lost for ATOMIC 
cache when key's primary node leaves topology. This closes #1133.

commit f597aff1bdf65d3d430cf85c9932391a72c2d7dc
Author: Andrey V. Mashenkov 
Date:   2016-10-12T12:44:08Z

IGNITE-3875: Added separate thread pool for data streamer. This closes 
#1067.

commit 2ab094e08373dc6667af44d48a38b4f044953a79
Author: tledkov-gridgain 
Date:   2016-10-12T13:48:51Z

IGNITE-2355: Hadoop: added ability to configure multiple job tracker 
addresses. This closes #1153.

commit eaf8ae246cc799c1353332fcac05cb3a8efab02c
Author: Pavel Tupitsyn 
Date:   2016-10-12T16:57:09Z

IGNITE-4034 Get rid of specialized methods in platform targets

commit b1ec58f716ece3a5866dd654ebc707bef67caf57
Author: Alexey Kuznetsov 
Date:   2016-10-13T05:58:22Z

IGNITE-4066 Fixed NPE.

commit 447e07c0bb5af75bce6a14612606904e4e3d9705
Author: Anton Vinogradov 
Date:   2016-10-14T08:40:41Z

IGNITE-1924 Incomplete marshaller cache rebalancing causes Grid hangs under 
SSL

commit 7adfbcf1ee7bbe0beb95fa82749a2e04449de8fa
Author: tledkov-gridgain 
Date:   2016-10-14T14:48:14Z

IGNITE-4060: Fixed a bug in RoundRobinLoadBalancing API causing exception 
when running closures after client node reconnect. This closes #1157.

commit 80abd1b72e4fc7b0b95212e7f53c700c0fe21156
Author: Aleksei Scherbakov 
Date:   2016-10-14T16:33:07Z

GG-11360 - Implement SQL queries cancellation (#18)

* GG-11360 Merged IGNITE-2680 to ignite-1.6.3.

* GG-11360 Test cleanup.

* GG-11360 Fixing broken tests.

* GG-11360 Fixing test.

* GG-11360 Fixing test.

* GG-11360 Fixing broken tests.

* GG-11360 Added test for forever-running query cancellation on node 
restart.

* GG-11360 Fixing race.

* GG-11360 Added test for forever-running query cancellation on node stop.

* GG-11360 Cleanup.

* GG-11360 Support for local query cancellation/timeout.

* GG-11360 Increase test duration.

* GG-11360 Remove redundant catch block.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Simplify test.

* GG-11360 Simplify test.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* Merge remote-tracking branch 'remotes/gg/ignite-1.6.10' into 
ignite-gg-11360

Conflicts:

modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

commit 43ac3f5d5e8ab664e07f26d99be34f284f7941dd
Author: vozerov-gridgain 
Date:   2016-10-17T08:26:12Z

IGNITE-4054: Hadoop: added map-reduce plan debug output.

commit d3f042b9ba6c605500ab7155c40a41850babefdb
Author: sboikov 
Date:   2016-10-17T09:28:31Z

Fixed indexing test in according to changes from #80abd1b.

commit 59de231c0d0dce56b0cf5c386b19a2880d9c0603
Author: sboikov 
D

Re: Merging all network components to a single one

[Yakov Zhdanov]

Dmitry, yes, your understanding is correct.

Denis, I remember I already shared the idea a while ago, but completely
forgot about the ticket. Thanks for bringing it up! You should give me
couple of tips on how to use "Search" function in Jira :)

Guys, this will be compatibility breaking change, as there will be no, for
example, discovery and communication SPIs. What if we move current
implementations to internal packages, introduce configuration
properties/beans so we can release and continue development in 2.0 without
breaking compatibility?

--Yakov

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

[ALEKSEY KUZNETSOV]

plz review ticket again

вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV :

> plz review ticket again
>
> пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk  >:
>
> Thanks, Aleksey,
>
> I will take a look this week.
>
> --AG
>
> 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Hi! Review my PR again, plz - https://github.com/apache/ignite/pull/1517
> >
> > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> >
> > > thanx! my next PR review will be in up source
> > >
> > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > Aleksey,
> > >
> > > I added a comment on GitHub, however, the community is moving towards
> the
> > > UpSource review tool, so I suggest you open a PR review in Ignite
> > UpSource:
> > > http://reviews.ignite.apache.org/ignite/
> > >
> > > After you've registered, you should be able to open a review.
> > >
> > > --AG
> > >
> > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Again, plz, review my PR :
> https://github.com/apache/ignite/pull/1517
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Continuations for services

[Vladimir Ozerov]

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 
> 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 
> > 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.
> > > > >
> > > >
> > > > Why not? The caller thread should block.
> > > >
> > >
> >
>

Re: Continuations for services

[Valentin Kulichenko]

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 
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 
> 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.
> > > >
> > >
> > > Why not? The caller thread should block.
> > >
> >
>

Re: IGNITE-13 (ready for review)

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

Hello everyone!

Colleagues, take a look please at the results of measuring.

Can I close this ticket ?

Should I add JMH benchmark and unit test to Ignite project ?

Results of measuring
https://github.com/javaller/mybenchmark/blob/master/out.txt

Benchmark
https://github.com/javaller/mybenchmark/blob/master/src/main/java/org/sample/ExampleTest.java

UTest
https://github.com/javaller/mybenchmark/blob/master/src/main/java/org/sample/BinaryMarshallerSelfTest.java

*results of measuring*
Benchmark
(message)  Mode  CntScore
Error  Units
LatchBenchmark.binaryHeapOutputStreamDirect
TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
LatchBenchmark.binaryHeapOutputStreamDirect
TestTestTestavgt   5044,934 ± 1,463  ns/op
LatchBenchmark.binaryHeapOutputStreamDirect
Test  avgt   5021,254 ± 0,776  ns/op
LatchBenchmark.binaryHeapOutputStreamInDirect
TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
LatchBenchmark.binaryHeapOutputStreamInDirect
TestTestTest   avgt   5058,975 ± 1,559  ns/op
LatchBenchmark.binaryHeapOutputStreamInDirect
Test avgt   5048,506 ± 1,116  ns/op


Vadim

2017-03-06 19:42 GMT+03:00 Вадим Опольский :

> Hello, everybody!
>
> Valentin, I've corrected benchmark and received the results:
>
> Benchmark
> (message)  Mode  Cnt
> Score   Error  Units
> LatchBenchmark.binaryHeapOutputStreamDirect
> TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
> LatchBenchmark.binaryHeapOutputStreamDirect
> TestTestTestavgt   5044,934 ± 1,463  ns/op
> LatchBenchmark.binaryHeapOutputStreamDirect
> Test  avgt   5021,254 ± 0,776  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> TestTestTest   avgt   5058,975 ± 1,559  ns/op
> LatchBenchmark.binaryHeapOutputStreamInDirect
> Test avgt   5048,506 ± 1,116  ns/op
>
> https://github.com/javaller/MyBenchmark/blob/master/out_06_03_17_2.txt
>
> Whats the next step ?
>
>  Do I have to add benchmark to Ignite project ?
>
> Vadim Opolskiy
>
> 2017-03-03 21:11 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Hi Vadim,
>>
>> What do you mean by "copied benchmarks"? What changed singe previous
>> iteration and why results are so different?
>>
>> As for duplicated loop, you don't need it. BinaryOutputStream allows to
>> write a value to a particular position (even before already written data).
>> So you can reserve 4 bytes for length, remember position, calculate length
>> while encoding and writing bytes, and then write length.
>>
>> -Val
>>
>> On Fri, Mar 3, 2017 at 12:45 AM, Вадим Опольский 
>> wrote:
>>
>>> Valentin,
>>>
>>> What do you think about duplicated cycle in strToBinaryOutputStream ?
>>>
>>> How to calculate StrLen для outBinaryHeap without this cycle ?
>>>
>>> public class BinaryUtilsNew extends BinaryUtils {
>>>
>>> public static int getStrLen(String val) {
>>> int strLen = val.length();
>>> int utfLen = 0;
>>> int c;
>>>
>>> // Determine length of resulting byte array.
>>>
>>>
>>>
>>>
>>> *for (int cnt = 0; cnt < strLen; cnt++) {c = val.charAt(cnt);   
>>>  if (c >= 0x0001 && c <= 0x007F)*utfLen++;
>>>* else if (c > 0x07FF)*
>>> utfLen += 3;
>>> else
>>> utfLen += 2;
>>> }
>>>
>>> return utfLen;
>>> }
>>>
>>> public static void strToUtf8BytesDirect(BinaryOutputStream 
>>> outBinaryHeap, String val) {
>>>
>>> int strLen = val.length();
>>> int c, cnt;
>>>
>>> int position = 0;
>>>
>>> outBinaryHeap.unsafeEnsure(1 + 4);
>>>
>>> *   outBinaryHeap.unsafeWriteByte(GridBinaryMarshaller.STRING);
>>> outBinaryHeap.unsafeWriteInt(getStrLen(val));*
>>>
>>>
>>>
>>> * for (cnt = 0; cnt < strLen; cnt++) {c = val.charAt(cnt);*
>>>* if (c >= 0x0001 && c <= 0x007F)*
>>> outBinaryHeap.writeByte((byte) c);
>>>  *   else if (c > 0x07FF) {*
>>> outBinaryHeap.writeByte((byte)(0xE0 | (c >> 12) & 0x0F));
>>> outBinaryHeap.writeByte((byte)(0x80 | (c >> 6) & 0x3F));
>>> outBinaryHeap.writeByte((byte)(0x80 | (c & 0x3F)));
>>> }
>>> else {
>>> outBinaryHeap.writeByte((byte)(0xC0 | ((c >> 6) & 0x1F)));
>>> outBinaryHeap.writeByte((byte)(0x80 | (c  & 0x3F)));
>>> }
>>> }
>>> }
>>>
>>>
>>> Vadim
>>>
>>>
>>>
>>> 2017-03-03 2:00 GMT+03:00 Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>>
 Vadim,

 Looks better now. Can 

[GitHub] ignite pull request #1604: Sorted merge index and SQL related fixes

[svladykin]

GitHub user svladykin opened a pull request:

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

Sorted merge index and SQL related fixes



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

$ git pull https://github.com/svladykin/ignite ignite-1.9-midx

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

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


commit fc42406a9e55851d53d9dfed8e6cf3c8b12af345
Author: Sergi Vladykin 
Date:   2017-02-23T13:46:39Z

ignite-1.9 - sorted index

commit ee9d524f5a0d6f1c416345822e8201c327f1e562
Author: Sergi Vladykin 
Date:   2017-02-24T13:00:26Z

ignite-1.9 - sorted index fixes

commit a639bff6f25a8397e49a892f830c9de23c847127
Author: Sergi Vladykin 
Date:   2017-02-26T17:08:26Z

ignite-1.9 - sorted index fixes2

commit 4ea63d7335000b8f30bfbd1bb907e411cd62a5e8
Author: Sergi Vladykin 
Date:   2017-02-26T19:44:51Z

ignite-1.9 - unsorted index fixed

commit 4ad048e248157d799a325b3ce9975d4ad8a9fb49
Author: Sergi Vladykin 
Date:   2017-02-26T20:19:49Z

ignite-1.9 - merge index

commit 0601ce6e291eb4689d526e922b02fd9e21df5b08
Author: Sergi Vladykin 
Date:   2017-02-26T20:24:14Z

ignite-1.9 - merge index test

commit a8751d535b3e025a804c441204465e94035a5247
Author: Sergi Vladykin 
Date:   2017-02-28T15:46:07Z

ignite-1.9 - splitter fixes

commit f1f1d96c6babaadab9e3ed1fbb3c9740c94d8209
Author: Sergi Vladykin 
Date:   2017-03-08T12:28:44Z

ignite-1.9.0 - fix for distributed join test

commit bc0801a3c976f5d87cab2c414f76f69dc28b43d7
Author: Sergi Vladykin 
Date:   2017-03-08T13:03:40Z

ignite-1.9.0 - fix for distributed join test

commit ff3c1f2967905b0bcac7661014656d1c080fa803
Author: Sergi Vladykin 
Date:   2017-03-09T08:08:34Z

ignite-1.9.0 - replicated subqueries fix




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