Re: Ignite 1.4

[Sergey Kozlov]

FYI: We've at least 161 unclosed issues planned to fix in version 1.4



On Tue, Sep 1, 2015 at 11:48 AM, Vladimir Ozerov 
wrote:

> I'm going to create a branch "ignite-1.4" for this release from master.
> Please let me know if anyone has concerns.
>
> On Mon, Aug 31, 2015 at 9:10 PM, Konstantin Boudnik 
> wrote:
>
> > On Mon, Aug 31, 2015 at 08:08PM, Branko Čibej wrote:
> > > On 31.08.2015 20:06, Konstantin Boudnik wrote:
> > > > Submitting for vote and releasing are two different events. The
> > release date
> > > > is when the vote is closed and its tally is counted.
> > >
> > > Heh, actually, the release date is when the release is announced. :)
> > > Which is typically after it's on all the mirrors, heh.
> >
> > Yeah, you right - sorry for the confusion ;)
> >
> > >
> > > -- Brane
> > >
> > > > On Mon, Aug 31, 2015 at 02:29PM, Yakov Zhdanov wrote:
> > > >> Guys,
> > > >>
> > > >> Here is the correct link to jira issues that should work for
> everyone
> > -
> > > >>
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20(status%20%3D%20resolved%20or%20status%20%3D%20closed)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >>
> > > >> Brane, if we are ready on Friday I would prefer to submit the build
> > for
> > > >> vote immediately. If not, Monday is still fine.
> > > >>
> > > >> Thanks!
> > > >> --
> > > >> Yakov
> > > >>
> > > >>
> > > >>
> > > >>> Plus 24 hours for mirrors to catch up.
> > > >>>
> > > >>> And a side note: a Friday release? Really? :)
> > > >>>
> > > >>> -- Brane
> > > >>>
> > > >>>
> > >
> >
>

Re: Ignite 1.4

[Konstantin Boudnik]

On Tue, Sep 01, 2015 at 08:45PM, Sergey Kozlov wrote:
> FYI: We've at least 161 unclosed issues planned to fix in version 1.4

If there're so many issues to go - perhaps it makes sense not to branch out
this early to avoid extra merges? 

Cos

> On Tue, Sep 1, 2015 at 11:48 AM, Vladimir Ozerov 
> wrote:
> 
> > I'm going to create a branch "ignite-1.4" for this release from master.
> > Please let me know if anyone has concerns.
> >
> > On Mon, Aug 31, 2015 at 9:10 PM, Konstantin Boudnik 
> > wrote:
> >
> > > On Mon, Aug 31, 2015 at 08:08PM, Branko Čibej wrote:
> > > > On 31.08.2015 20:06, Konstantin Boudnik wrote:
> > > > > Submitting for vote and releasing are two different events. The
> > > release date
> > > > > is when the vote is closed and its tally is counted.
> > > >
> > > > Heh, actually, the release date is when the release is announced. :)
> > > > Which is typically after it's on all the mirrors, heh.
> > >
> > > Yeah, you right - sorry for the confusion ;)
> > >
> > > >
> > > > -- Brane
> > > >
> > > > > On Mon, Aug 31, 2015 at 02:29PM, Yakov Zhdanov wrote:
> > > > >> Guys,
> > > > >>
> > > > >> Here is the correct link to jira issues that should work for
> > everyone
> > > -
> > > > >>
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20(status%20%3D%20resolved%20or%20status%20%3D%20closed)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > > >>
> > > > >> Brane, if we are ready on Friday I would prefer to submit the build
> > > for
> > > > >> vote immediately. If not, Monday is still fine.
> > > > >>
> > > > >> Thanks!
> > > > >> --
> > > > >> Yakov
> > > > >>
> > > > >>
> > > > >>
> > > > >>> Plus 24 hours for mirrors to catch up.
> > > > >>>
> > > > >>> And a side note: a Friday release? Really? :)
> > > > >>>
> > > > >>> -- Brane
> > > > >>>
> > > > >>>
> > > >
> > >
> >

Re: Ignite 1.4

[Branko Čibej]

On 01.09.2015 20:46, Konstantin Boudnik wrote:
> On Tue, Sep 01, 2015 at 08:45PM, Sergey Kozlov wrote:
>> FYI: We've at least 161 unclosed issues planned to fix in version 1.4
> If there're so many issues to go - perhaps it makes sense not to branch out
> this early to avoid extra merges? 

Or just go ahead and release 1.4 and get those issues addressed in 1.5.
It's not as if skipping a  "planned to fix" issue would be the end of
the world.

-- Brane

[jira] [Created] (IGNITE-1338) SQL engine doesn't convert query fields name in upper case before using

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1338:
--

 Summary: SQL engine doesn't convert query fields name in upper 
case before using
 Key: IGNITE-1338
 URL: https://issues.apache.org/jira/browse/IGNITE-1338
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: ignite-1.4
Reporter: Pavel Konstantinov
Assignee: Sergi Vladykin
Priority: Minor
 Fix For: ignite-1.4


I'm played with Ignite control center and found this bug.
I'm attached example xml-file.



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

Download page on the Ignite website

[Branko Čibej]

Guys,

I just updated the download page magic because Infra made a major change
in the way download scripts work last night.

As I was doing this, I noticed that someone ripped out the logic that
made the site offer downloads from our closest mirror instead of
*straight out of the repository*.

How many times do I have to explain that we do *not* tell people to
download our releases straight off the ASF infrastructure? Why do you
think ASF Infra goes to all the trouble to maintain mirror lists and
geoip-aware scripting to make automatic (and manual) mirror selection
possible?

Whoever did this, please put the logic for automatic and manual mirror
selection back, preferably yesterday.

-- Brane

Re: Coding style changed!

[Denis Magda]

I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to reflect the 
changes.


--
Denis

On 8/31/2015 5:48 PM, Sergi Vladykin wrote:

Guys,

As discussed, I changed all the imports in master to explicit ones.

Settings for Idea you can see here:
https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png

Coding guidelines will be updated soon.

Sergi

Re: website changes

[Dmitriy Setrakyan]

Raul,

Sorry for the late reply, but better late than never :)

On Mon, Aug 24, 2015 at 4:30 AM, Raul Kripalani  wrote:

> wget spider output here:
> https://gist.github.com/raulk/7d6713aa7b3d21ecaacd
>
> No issues with regards to the domain migration, but we have 404 in
> robots.txt and some jquery JS across many pages.
>
> I also ran a spider on our readme.io docs, and it was quite OK except that
> it found these 404s:
>
> --2015-08-24 12:16:43--
> https://apacheignite.readme.io/docs/distributed-closures%22  HTTP/1.1 404
> Not Found
> --2015-08-24 12:26:04--
> https://apacheignite.readme.io/docs/%7B%7Burl('v'%20+%20v.version)%7D%7D
>  HTTP/1.1 404 Not Found
>
>
Raul, is there a way to find out the referrer pages that have these links?


> With regards to the jquery URL references:
>
> --2015-08-24 12:19:31--
> http://ignite.apache.org/use-cases/spark/js/jquery-1.11.1.min.js
>   HTTP/1.1 404 Not Found
> --2015-08-24 12:19:27--
> http://ignite.apache.org/use-cases/caching/js/jquery-1.11.1.min.js
>   HTTP/1.1 404 Not Found
>

Prachi, any chance you can look at these?


>
> Are some examples. I guess these HTMLs are referring to jquery in the
> context directory rather than in a common directory.
>
> Do you think it makes sense to add a robots.txt for SEO purposes?
>

Raul, I am not sure what we would put into robots.txt. Is there any benefit
in having this file vs not having it?


>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Mon, Aug 24, 2015 at 10:45 AM, Dmitriy Setrakyan  >
> wrote:
>
> > Igniters,
> >
> > I have updated the Ignite website to reflect the project graduation
> (turned
> > out that many links were not working).
> >
> > Would be nice if the community clicked around and verified that all the
> > links are working and all the wording and examples are correct.
> >
> > Thanks,
> > D.
> >
>

Re: Download page on the Ignite website

[Dmitriy Setrakyan]

Brane,

I have fixed it. The reason it was pointing to the apache repo is because
the download mirrors were broken for several days during the graduation
upgrade, and while the INFRA issues were resolved, we had to redirect the
downloads to the main repo.

Another weird issue I noticed now is that there are only 2 mirrors listed.
Is this the way it is supposed to be now?

D.

On Tue, Sep 1, 2015 at 12:36 AM, Branko Čibej  wrote:

> Guys,
>
> I just updated the download page magic because Infra made a major change
> in the way download scripts work last night.
>
> As I was doing this, I noticed that someone ripped out the logic that
> made the site offer downloads from our closest mirror instead of
> *straight out of the repository*.
>
> How many times do I have to explain that we do *not* tell people to
> download our releases straight off the ASF infrastructure? Why do you
> think ASF Infra goes to all the trouble to maintain mirror lists and
> geoip-aware scripting to make automatic (and manual) mirror selection
> possible?
>
> Whoever did this, please put the logic for automatic and manual mirror
> selection back, preferably yesterday.
>
> -- Brane
>

Re: Hello

[Charles Cobb]

My group and I are sufficiently experienced with Java. We are not experts,
but we are very good programmers (or so I think; we've all had internships
and have taken a bunch of programming classes). Java is the first language
we learned and the main language used in 3 required programming classes
here at Penn. I programmed in mostly Scala all summer, working with Apache
Spark. We are also comfortable with threads and concurrency.

I'm more interested in 1 big task, but if the smaller tasks are connected
through some common concepts, that would work fine too.

On Mon, Aug 31, 2015 at 8:51 PM, Dmitriy Setrakyan 
wrote:

> Hi Charles,
>
> Welcome you to the Ignite community!
>
> First of all, please properly subscribe to the dev list (it seems that you
> still are not subscribed). You should send an email to
> dev-subscr...@ignite.apache.org and follow instructions in the reply.
>
> There are several features in Ignite that you could work for a year or so
> and contribute. However, before we get into that discussion, can you please
> let us know the level of expertise in your group, specifically as it
> relates to Java programming?
>
> Also, are you interested mainly in 1 big task, or would multiple smaller
> tasks be OK as well?
>
> Thanks,
> D.
>
> On Mon, Aug 31, 2015 at 5:27 PM, Charles Cobb 
> wrote:
>
>> Hi all,
>>
>> My name is CJ, and I'm very interested in Apache Ignite. In fact, I'm a
>> senior at UPenn and am looking for a year long project to work on. Is
>> there
>> any larger portion of Apache Ignite that is not implemented or minimally
>> implemented that I and a few other people could work on for a year? I feel
>> the tickets on the Ignite site are a little too small to work on as a year
>> long project.
>>
>> Best,
>>
>> --
>> Charles Cobb
>> University of Pennsylvania '16
>> Computer Science
>> charc...@seas.upenn.edu
>>
>
>


-- 
Charles Cobb
University of Pennsylvania '16
Computer Science
charc...@seas.upenn.edu

[jira] [Created] (IGNITE-1339) JVM Crash on TC Queries suite

[Sergi Vladykin (JIRA)]

Sergi Vladykin created IGNITE-1339:
--

 Summary: JVM Crash on TC Queries suite
 Key: IGNITE-1339
 URL: https://issues.apache.org/jira/browse/IGNITE-1339
 Project: Ignite
  Issue Type: Bug
Reporter: Sergi Vladykin
Priority: Critical
 Fix For: ignite-1.4


{code}
[07:13:33][org.apache.ignite:ignite-indexing] 
[07:12:05,772][ERROR][ignite-#53702%sys-cache.IgniteCacheOffheapTieredMultithreadedSelfTest2%][GridMapQueryExecutor]
 Failed to process message: GridQueryRequest [reqId=1712, pageSize=1024, 
space=null, qrys=[GridCacheSqlQuery [alias=__Z0(), qry=SELECT
[07:13:33][org.apache.ignite:ignite-indexing] "".PERSON._KEY __C0,
[07:13:33][org.apache.ignite:ignite-indexing] "".PERSON._VAL __C1
[07:13:33][org.apache.ignite:ignite-indexing] FROM "".PERSON
[07:13:33][org.apache.ignite:ignite-indexing] WHERE (SALARY >= ?1) AND (SALARY 
<= ?2), params=[9.48320472052535E8, 9.48321472052535E8]]], 
topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], extraSpaces=null, 
parts=[0, 1, 3, 6, 7, 8, 10, 11, 12, 13, 14, 17, 18, 19, 23, 25, 26, 27, 28, 
29, 30, 31, 32, 33, 34, 35, 36, 38, 39, 40, 41, 42, 44, 45, 46, 47, 51, 53, 54, 
55, 58, 59, 60, 61, 62, 63, 68, 69, 72, 73, 75, 76, 78, 80, 81, 82, 85, 86, 87, 
88, 89, 90, 91, 94, 95, 98, 101, 102, 105, 106, 109, 110, 111, 114, 116, 117, 
119, 120, 121, 122, 123, 125, 126, 127, 128, 129, 130, 133, 134, 135, 137, 139, 
140, 141, 145, 147, 149, 151, 153, 154, 155, 156, 157, 158, 159, 161, 162, 163, 
164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 177, 178, 181, 183, 
184, 186, 187, 188, 189, 190, 191, 192, 194, 195, 196, 198, 199, 200, 201, 205, 
206, 208, 209, 211, 212, 213, 214, 215, 217, 218, 219, 220, 221, 222, 223, 224, 
225, 227, 231, 232, 234, 236, 237, 240, 241, 242, 243, 245, 246, 247, 248, 250, 
251, 253, 254, 255, 257, 258, 259, 260, 261, 263, 264, 265, 266, 268, 269, 270, 
272, 273, 274, 276, 277, 278, 279, 280, 282, 283, 285, 287, 288, 290, 292, 293, 
294, 296, 298, 300, 301, 302, 308, 309, 311, 314, 315, 317, 318, 319, 320, 321, 
322, 324, 325, 327, 328, 329, 330, 331, 332, 333, 334, 340, 342, 343, 345, 346, 
350, 352, 353, 354, 356, 358, 359, 360, 364, 365, 366, 368, 371, 372, 373, 375, 
376, 379, 380, 381, 382, 384, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 
396, 397, 398, 399, 400, 401, 402, 403, 405, 407, 409, 410, 412, 413, 414, 416, 
417, 420, 421, 422, 423, 424, 429, 430, 431, 432, 433, 435, 436, 437, 438, 439, 
441, 442, 443, 444, 445, 446, 448, 449, 451, 453, 454, 456, 458, 459, 460, 461, 
462, 463, 464, 465, 466, 467, 469, 470, 471, 472, 473, 476, 477, 479, 480, 482, 
484, 486, 487, 488, 489, 490, 491, 492, 493, 495, 497, 501, 502, 505, 507, 508, 
511, 512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 
527, 528, 532, 534, 535, 537, 538, 541, 542, 543, 544, 545, 546, 547, 548, 549, 
550, 551, 552, 553, 557, 558, 559, 561, 562, 563, 565, 566, 568, 569, 571, 573, 
575, 576, 578, 579, 582, 583, 585, 586, 590, 592, 593, 594, 595, 596, 597, 598, 
599, 603, 604, 605, 606, 607, 608, 609, 611, 612, 614, 615, 617, 618, 619, 620, 
623, 624, 625, 627, 628, 629, 631, 632, 633, 634, 635, 636, 637, 639, 641, 643, 
644, 645, 646, 647, 648, 649, 652, 654, 656, 657, 658, 659, 660, 662, 663, 664, 
665, 667, 668, 669, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 
683, 685, 686, 687, 688, 689, 692, 694, 696, 698, 699, 700, 701, 703, 706, 707, 
710, 712, 713, 715, 716, 717, 718, 719, 723, 725, 727, 728, 729, 730, 732, 733, 
734, 735, 736, 738, 741, 742, 743, 744, 746, 747, 749, 751, 752, 753, 758, 759, 
760, 762, 764, 766, 767, 768, 769, 771, 773, 775, 776, 777, 780, 781, 782, 783, 
786, 789, 790, 791, 792, 796, 799, 801, 802, 804, 809, 813, 814, 815, 816, 817, 
819, 820, 821, 822, 824, 825, 827, 829, 830, 832, 833, 841, 843, 844, 845, 846, 
847, 848, 849, 850, 851, 852, 855, 857, 859, 860, 862, 864, 865, 867, 868, 869, 
870, 872, 874, 875, 876, 879, 881, 883, 884, 885, 886, 887, 888, 889, 890, 892, 
894, 896, 898, 899, 901, 902, 903, 904, 906, 908, 909, 911, 912, 913, 914, 917, 
918, 919, 920, 921, 922, 925, 927, 929, 931, 932, 934, 935, 938, 939, 940, 941, 
942, 943, 945, 946, 948, 949, 950, 952, 955, 957, 959, 960, 961, 962, 964, 965, 
967, 968, 969, 971, 972, 974, 975, 976, 977, 979, 980, 981, 984, 985, 989, 990, 
991, 993, 995, 997, 998, 999, 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 
1008, 1009, 1010, 1012, 1013, 1014, 1015, 1016, 1017, 1019, 1020, 1021, 1022]]
[07:13:33][org.apache.ignite:ignite-indexing] class 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
 [part=31, msg=Creating partition which does not belong [part=31, 
topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], 
this.topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0]]]
[07:13:33][org.apache.ignite:ignite-indexing]   at 

[jira] [Created] (IGNITE-1340) Platforms .Net: Fix PlatformCachePartialUpdateException propagation

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1340:
---

 Summary: Platforms .Net: Fix PlatformCachePartialUpdateException 
propagation
 Key: IGNITE-1340
 URL: https://issues.apache.org/jira/browse/IGNITE-1340
 Project: Ignite
  Issue Type: Improvement
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: ignite-1.4


PlatformCachePartialUpdateException should be thrown from PlatformCache in 
sync/async mode when 
CachePartialUpdateCheckedException/CachePartialUpdateException occurs.



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

Re: IGNITE-708

[Gianfranco Murador]

Hello Alexey,
I mean 'local partition map'. I am trying to investigate the issue, and in
fact,
I need some clarification about the ticket. From my understanding, It is
necessary to refresh the partitions (refreshPartitions())
only if the local partition is changed, or if a transaction has been made
on it. So if I understand I need to add logic and control
in the OnTimeOut method of the inner class . Is it correct ?

/** {@inheritDoc} */
@Override public void onTimeout() {
cctx.kernalContext().closure().runLocalSafe(new Runnable() {
@Override public void run() {
if (!busyLock.readLock().tryLock())
return;

try {
   // onTimeOut we refresh always the partitions
  if (started.compareAndSet(false, true))
refreshPartitions();
}
finally {
busyLock.readLock().unlock();

cctx.time().removeTimeoutObject(ResendTimeoutObject.this);

pendingResend.compareAndSet(ResendTimeoutObject.this, null);
}
}
});
}

Thank you, Regards, Gianfranco

2015-09-01 3:30 GMT+02:00 Dmitriy Setrakyan :

> On Mon, Aug 31, 2015 at 5:57 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > As far as I understood Yakov's point, even this message indicating that
> no
> > change happened is redundant because we have message delivery guarantees
> on
> > communication level and no messages can be lost. If a node is waiting
> for a
> > message and receives a message indicating that no change had happened, I
> am
> > not even sure how this node should react: it means that the message with
> an
> > important update somehow was not received (a bug in the code?) and the
> next
> > message indicates that no updates after the lost message were made.
> >
>
> I still would wait for a No-Change empty partition exchange message, rather
> than have no message at all (and wait for a timeout?).
>
> Yakov, can you please chime in and let us all know what you meant by that
> ticket?
>
>
> >
> > 2015-08-31 17:33 GMT-07:00 Dmitriy Setrakyan :
> >
> > > On Mon, Aug 31, 2015 at 4:58 PM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Gianfranco,
> > > >
> > > > What do you mean by 'local cache' here?
> > > >
> > > > If you are talking about the local partition map, I do not think we
> > have
> > > > such a method. The background exchange that is described in the
> ticket
> > is
> > > > handled in controlled by the ResendTimeoutObject inner class in
> > > > GridCachePartitionExchangeManager. I cannot recall any cases when
> this
> > > > exchange would be needed from the top of my head, but it looks like
> you
> > > > need to do some investigation and code digging to check whether the
> > > > background exchange can be indeed safely removed :)
> > > >
> > >
> > > Alexey, I actually think that this ticket is named wrongly. After
> looking
> > > at the description, it seems that Yakov is suggesting that we do not
> send
> > > the exchange message if there are no changes to the exchange. Perhaps,
> we
> > > should be still sending something indicating that no change happened,
> > > otherwise, other nodes will hang forever waiting for the exchange to
> > > complete.
> > >
> > > Am I wrong in my understanding?
> > >
> > >
> > >
> > > >
> > > > 2015-08-28 5:58 GMT-07:00 Gianfranco Murador :
> > > >
> > > > > Hi Igniters,
> > > > > I 'm starting to implement this patch:
> > > > > Can you tell me if there is already a convenient method to see if
> the
> > > > local
> > > > > cache was updated last time interval ?
> > > > > Regards, Gianfranco
> > > > >
> > > > >
> > > > > --
> > > > > Gianfranco Murador
> > > > > Igniter and Software Engineer.
> > > > >
> > > >
> > >
> >
>

Re: Ignite 1.4

[Vladimir Ozerov]

I'm going to create a branch "ignite-1.4" for this release from master.
Please let me know if anyone has concerns.

On Mon, Aug 31, 2015 at 9:10 PM, Konstantin Boudnik  wrote:

> On Mon, Aug 31, 2015 at 08:08PM, Branko Čibej wrote:
> > On 31.08.2015 20:06, Konstantin Boudnik wrote:
> > > Submitting for vote and releasing are two different events. The
> release date
> > > is when the vote is closed and its tally is counted.
> >
> > Heh, actually, the release date is when the release is announced. :)
> > Which is typically after it's on all the mirrors, heh.
>
> Yeah, you right - sorry for the confusion ;)
>
> >
> > -- Brane
> >
> > > On Mon, Aug 31, 2015 at 02:29PM, Yakov Zhdanov wrote:
> > >> Guys,
> > >>
> > >> Here is the correct link to jira issues that should work for everyone
> -
> > >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20(status%20%3D%20resolved%20or%20status%20%3D%20closed)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >>
> > >> Brane, if we are ready on Friday I would prefer to submit the build
> for
> > >> vote immediately. If not, Monday is still fine.
> > >>
> > >> Thanks!
> > >> --
> > >> Yakov
> > >>
> > >>
> > >>
> > >>> Plus 24 hours for mirrors to catch up.
> > >>>
> > >>> And a side note: a Friday release? Really? :)
> > >>>
> > >>> -- Brane
> > >>>
> > >>>
> >
>

[jira] [Created] (IGNITE-1341) Platforms: refactor exceptions.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1341:
---

 Summary: Platforms: refactor exceptions.
 Key: IGNITE-1341
 URL: https://issues.apache.org/jira/browse/IGNITE-1341
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.4


1) Move exceptions from "platforms" to "core".
2) PlatformNativeException: move from "compute" to base package.
3) PlatormExtendedException: incorporate into regular exception hierarchy.
4) PlatformContext.createNativeException must return PlatformNativeException.



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

Re: Please help to do the code review for those newbie PR

[Ken Cheng]

Hi Alexey,


yes, just as you said, if the node start with client mode

 cfg.setClientMode(true);

Then the case will fail, I have implemented the method as you advised.
please help to review the PR

Thanks,
kcheng

On Tue, Sep 1, 2015 at 9:51 AM, Alexey Goncharuk  wrote:

> Ken,
>
> I have also provided some feedback regarding the IGNTIE-1226 ticket (sorry
> it took a long time to respond to your previous email).
>
> 2015-08-31 18:48 GMT-07:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Hi Ken,
> >
> > I was just in process of reviewing them :) Please give me couple more
> hours
> > and I will provide feedback.
> >
> > -Val
> >
> > On Mon, Aug 31, 2015 at 6:47 PM, Ken Cheng  wrote:
> >
> > > Hi Valentin Kulichenko*  &  *Alexey Kuznetsov
> > >
> > > Can you help to do the code review for the newbie bugs
> > >
> > > Jira:
> > > https://issues.apache.org/jira/browse/IGNITE-1226
> > > https://issues.apache.org/jira/browse/IGNITE-1153
> > >
> > > PR:
> > >
> > > https://github.com/apache/ignite/pull/35
> > > https://github.com/apache/ignite/pull/44
> > >
> > >
> > > Thanks,
> > > kcheng
> > >
> > > On Mon, Aug 31, 2015 at 2:11 PM, Ken Cheng 
> wrote:
> > >
> > > > Hi devs,
> > > >
> > > > https://github.com/apache/ignite/pull/35
> > > > https://github.com/apache/ignite/pull/44
> > > >
> > > >
> > > > Thanks,
> > > > kcheng
> > > >
> > >
> >
>

Re: IGNITE-708

[Gianfranco Murador]

Thank you , all.


2015-09-01 12:21 GMT+02:00 Yakov Zhdanov :

> In my view, Alex has 100% understanding on what is hapenning. Let's remove
> background exchange if partition map does not change. Gianfranco, I don't
> think you should  account for transactions. Only updates to partition
> topology matters. Younger nodes should send local updates to the oldest.
> The oldest one should spread partitions after some delay buffering possible
> updates or similar messages from other nodes.
>
> Hope this helps!
> On Sep 1, 2015 11:14, "Gianfranco Murador" 
> wrote:
>
> > Hello Alexey,
> > I mean 'local partition map'. I am trying to investigate the issue, and
> in
> > fact,
> > I need some clarification about the ticket. From my understanding, It is
> > necessary to refresh the partitions (refreshPartitions())
> > only if the local partition is changed, or if a transaction has been made
> > on it. So if I understand I need to add logic and control
> > in the OnTimeOut method of the inner class . Is it correct ?
> >
> > /** {@inheritDoc} */
> > @Override public void onTimeout() {
> > cctx.kernalContext().closure().runLocalSafe(new Runnable() {
> > @Override public void run() {
> > if (!busyLock.readLock().tryLock())
> > return;
> >
> > try {
> >// onTimeOut we refresh always the partitions
> >   if (started.compareAndSet(false, true))
> > refreshPartitions();
> > }
> > finally {
> > busyLock.readLock().unlock();
> >
> > cctx.time().removeTimeoutObject(ResendTimeoutObject.this);
> >
> > pendingResend.compareAndSet(ResendTimeoutObject.this, null);
> > }
> > }
> > });
> > }
> >
> > Thank you, Regards, Gianfranco
> >
> > 2015-09-01 3:30 GMT+02:00 Dmitriy Setrakyan :
> >
> > > On Mon, Aug 31, 2015 at 5:57 PM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > As far as I understood Yakov's point, even this message indicating
> that
> > > no
> > > > change happened is redundant because we have message delivery
> > guarantees
> > > on
> > > > communication level and no messages can be lost. If a node is waiting
> > > for a
> > > > message and receives a message indicating that no change had
> happened,
> > I
> > > am
> > > > not even sure how this node should react: it means that the message
> > with
> > > an
> > > > important update somehow was not received (a bug in the code?) and
> the
> > > next
> > > > message indicates that no updates after the lost message were made.
> > > >
> > >
> > > I still would wait for a No-Change empty partition exchange message,
> > rather
> > > than have no message at all (and wait for a timeout?).
> > >
> > > Yakov, can you please chime in and let us all know what you meant by
> that
> > > ticket?
> > >
> > >
> > > >
> > > > 2015-08-31 17:33 GMT-07:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Mon, Aug 31, 2015 at 4:58 PM, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com> wrote:
> > > > >
> > > > > > Gianfranco,
> > > > > >
> > > > > > What do you mean by 'local cache' here?
> > > > > >
> > > > > > If you are talking about the local partition map, I do not think
> we
> > > > have
> > > > > > such a method. The background exchange that is described in the
> > > ticket
> > > > is
> > > > > > handled in controlled by the ResendTimeoutObject inner class in
> > > > > > GridCachePartitionExchangeManager. I cannot recall any cases when
> > > this
> > > > > > exchange would be needed from the top of my head, but it looks
> like
> > > you
> > > > > > need to do some investigation and code digging to check whether
> the
> > > > > > background exchange can be indeed safely removed :)
> > > > > >
> > > > >
> > > > > Alexey, I actually think that this ticket is named wrongly. After
> > > looking
> > > > > at the description, it seems that Yakov is suggesting that we do
> not
> > > send
> > > > > the exchange message if there are no changes to the exchange.
> > Perhaps,
> > > we
> > > > > should be still sending something indicating that no change
> happened,
> > > > > otherwise, other nodes will hang forever waiting for the exchange
> to
> > > > > complete.
> > > > >
> > > > > Am I wrong in my understanding?
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > 2015-08-28 5:58 GMT-07:00 Gianfranco Murador  >:
> > > > > >
> > > > > > > Hi Igniters,
> > > > > > > I 'm starting to implement this patch:
> > > > > > > Can you tell me if there is already a convenient method to see
> if
> > > the
> > > > > > local
> > > > > > > cache was updated last time interval ?
> > > > > > > Regards, Gianfranco
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Gianfranco Murador
> > > > > > > Igniter and Software Engineer.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: IGNITE-708

[Dmitriy Setrakyan]

On Tue, Sep 1, 2015 at 3:21 AM, Yakov Zhdanov  wrote:

> In my view, Alex has 100% understanding on what is hapenning. Let's remove
> background exchange if partition map does not change. Gianfranco, I don't
> think you should  account for transactions. Only updates to partition
> topology matters. Younger nodes should send local updates to the oldest.
> The oldest one should spread partitions after some delay buffering possible
> updates or similar messages from other nodes.
>

I think I have finally understood the issue. You are talking about
partition map not changing across the whole cluster, not just on one node,
correct? In that case it absolutely does makes sense, Partition Map
Exchange should not happen if the partition map on any of the nodes did not
change.


>
> Hope this helps!
> On Sep 1, 2015 11:14, "Gianfranco Murador" 
> wrote:
>
> > Hello Alexey,
> > I mean 'local partition map'. I am trying to investigate the issue, and
> in
> > fact,
> > I need some clarification about the ticket. From my understanding, It is
> > necessary to refresh the partitions (refreshPartitions())
> > only if the local partition is changed, or if a transaction has been made
> > on it. So if I understand I need to add logic and control
> > in the OnTimeOut method of the inner class . Is it correct ?
> >
> > /** {@inheritDoc} */
> > @Override public void onTimeout() {
> > cctx.kernalContext().closure().runLocalSafe(new Runnable() {
> > @Override public void run() {
> > if (!busyLock.readLock().tryLock())
> > return;
> >
> > try {
> >// onTimeOut we refresh always the partitions
> >   if (started.compareAndSet(false, true))
> > refreshPartitions();
> > }
> > finally {
> > busyLock.readLock().unlock();
> >
> > cctx.time().removeTimeoutObject(ResendTimeoutObject.this);
> >
> > pendingResend.compareAndSet(ResendTimeoutObject.this, null);
> > }
> > }
> > });
> > }
> >
> > Thank you, Regards, Gianfranco
> >
> > 2015-09-01 3:30 GMT+02:00 Dmitriy Setrakyan :
> >
> > > On Mon, Aug 31, 2015 at 5:57 PM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > As far as I understood Yakov's point, even this message indicating
> that
> > > no
> > > > change happened is redundant because we have message delivery
> > guarantees
> > > on
> > > > communication level and no messages can be lost. If a node is waiting
> > > for a
> > > > message and receives a message indicating that no change had
> happened,
> > I
> > > am
> > > > not even sure how this node should react: it means that the message
> > with
> > > an
> > > > important update somehow was not received (a bug in the code?) and
> the
> > > next
> > > > message indicates that no updates after the lost message were made.
> > > >
> > >
> > > I still would wait for a No-Change empty partition exchange message,
> > rather
> > > than have no message at all (and wait for a timeout?).
> > >
> > > Yakov, can you please chime in and let us all know what you meant by
> that
> > > ticket?
> > >
> > >
> > > >
> > > > 2015-08-31 17:33 GMT-07:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Mon, Aug 31, 2015 at 4:58 PM, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com> wrote:
> > > > >
> > > > > > Gianfranco,
> > > > > >
> > > > > > What do you mean by 'local cache' here?
> > > > > >
> > > > > > If you are talking about the local partition map, I do not think
> we
> > > > have
> > > > > > such a method. The background exchange that is described in the
> > > ticket
> > > > is
> > > > > > handled in controlled by the ResendTimeoutObject inner class in
> > > > > > GridCachePartitionExchangeManager. I cannot recall any cases when
> > > this
> > > > > > exchange would be needed from the top of my head, but it looks
> like
> > > you
> > > > > > need to do some investigation and code digging to check whether
> the
> > > > > > background exchange can be indeed safely removed :)
> > > > > >
> > > > >
> > > > > Alexey, I actually think that this ticket is named wrongly. After
> > > looking
> > > > > at the description, it seems that Yakov is suggesting that we do
> not
> > > send
> > > > > the exchange message if there are no changes to the exchange.
> > Perhaps,
> > > we
> > > > > should be still sending something indicating that no change
> happened,
> > > > > otherwise, other nodes will hang forever waiting for the exchange
> to
> > > > > complete.
> > > > >
> > > > > Am I wrong in my understanding?
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > 2015-08-28 5:58 GMT-07:00 Gianfranco Murador  >:
> > > > > >
> > > > > > > Hi Igniters,
> > > > > > > I 'm starting to implement this patch:
> > > > > > > Can you tell me if there is already a convenient method to see
> if
> > > the
> > > > > > local
> > > > > > > cache was updated last time interval ?
> > > > > > > Regards, Gianfranco
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >