Re: Ordering updates on backups in ATOMIC cache
If non sync evicts are configured, then cyclic buffer should be used. No? Thanks! Yakov On Sep 11, 2015 09:03, "Alexey Goncharuk" wrote: > Guys, > > I was thinking about ordering updates on backups so that we are able to > send entry processors on backups as we do in TRANSACTIONAL cache. > > What if we send not only the new version of an entry, but also the old > version (the one that was replaced). > > Let's say we have an entry with version v0, and we apply updates with > versions v1, v2, v3. Instead of sending just (val1, ver1), (val2, ver2), > (val3, ver3) we can send (val1, ver0->ver1), (val2, ver1->ver2), (val3, > ver2->ver3). In this case even if updated are processed on a backup node in > a different order, we can queue updates and wait until all updates are > received (like we did for ordered messages a while ago). > > The only concern that I have is that independent evicts cannot happen on a > backup node because the version of an entry should always match on primary > and backup nodes - so we should always initiate evict from primary node and > use version to evict an entry - basically, treat evict as a remove, but > with no write-through. > > Thoughts? >
Ordering updates on backups in ATOMIC cache
Guys, I was thinking about ordering updates on backups so that we are able to send entry processors on backups as we do in TRANSACTIONAL cache. What if we send not only the new version of an entry, but also the old version (the one that was replaced). Let's say we have an entry with version v0, and we apply updates with versions v1, v2, v3. Instead of sending just (val1, ver1), (val2, ver2), (val3, ver3) we can send (val1, ver0->ver1), (val2, ver1->ver2), (val3, ver2->ver3). In this case even if updated are processed on a backup node in a different order, we can queue updates and wait until all updates are received (like we did for ordered messages a while ago). The only concern that I have is that independent evicts cannot happen on a backup node because the version of an entry should always match on primary and backup nodes - so we should always initiate evict from primary node and use version to evict an entry - basically, treat evict as a remove, but with no write-through. Thoughts?
Fwd: Only 7 days left to save Bay Area In-Memory Computing Meetup
I got this email a couple of days ago. And am wondering if this is something that this group would be interested of taking over? Thoughts? Cos - Forwarded message from Meetup - Date: Sun, 6 Sep 2015 10:23:15 -0400 From: Meetup To: c...@apache.org Subject: Only 7 days left to save Bay Area In-Memory Computing Meetup Hi Cos, Nobody has stepped up yet to become the new Organizer of Bay Area In-Memory Computing Meetup. There are only 7 days left before the group is shut down and removed from Meetup.com forever. As the new Organizer you can lead Bay Area In-Memory Computing Meetup, guide its direction, its Meetups, and who's involved, change the look, the colors, and the name of the group! You and your members can change the Meetup Group any way you want. KEEP YOUR GROUP GOING: http://www.meetup.com/Bay-Area-In-Memory-Computing/handover/?op=c&ic=en7 Got questions? We're here to help! Send us an email at supp...@meetup.com Viva la community! The Team at Meetup HQ -- Add i...@meetup.com to your address book to receive all Meetup emails To manage your email settings, go to: http://www.meetup.com/account/comm/ Meetup, POB 4668 #37895 NY NY USA 10163 Meetup HQ in NYC is hiring! http://www.meetup.com/jobs/ - End forwarded message -
[GitHub] ignite pull request: IGNITE-1378 - Fixed exception handling in Gri...
GitHub user vkulichenko opened a pull request: https://github.com/apache/ignite/pull/83 IGNITE-1378 - Fixed exception handling in GridContinuousProcessor You can merge this pull request into a Git repository by running: $ git pull https://github.com/vkulichenko/incubator-ignite ignite-1378 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/83.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 #83 commit 4f652966c956e8a04576c1b60089ba34d052b7a1 Author: Valentin Kulichenko Date: 2015-09-08T20:35:35Z IGNITE-1378 - Fixed exception handling in GridContinuousProcessor.startRoutine() commit 6cda6ec91d7d7be588eda57e62dbfe06153ceee9 Author: Valentin Kulichenko Date: 2015-09-11T01:36:58Z Merge branch 'ignite-1.4' into ignite-1378 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNITE-1402 - Fixed logging categories
GitHub user vkulichenko opened a pull request: https://github.com/apache/ignite/pull/82 IGNITE-1402 - Fixed logging categories You can merge this pull request into a Git repository by running: $ git pull https://github.com/vkulichenko/incubator-ignite ignite-1402 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/82.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 #82 commit ed6984644a3a575f1f0ffb5eb9b834ad855f8fae Author: Valentin Kulichenko Date: 2015-09-11T01:31:56Z IGNITE-1402 - Fixed logging categories --- 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: website changes
On Thu, Sep 10, 2015 at 05:38PM, Prachi Garg wrote:
> I've created Google site verification for both, http and https version of
> Ignite website. I've also added sitemap.xml and robots.txt.
>
> If I may, I would like to suggest a server-side 301 redirect from http to
> https version of the website to ensure that users and search engines are
> directed to the preferred protocol (I'm guessing https pages are preferred
> over http pages).
That's a good idea! I guess not everyone just installs HttpsEverywhere and
forget that the websites still handle non-secure transport ;)
Cos
> Thanks,
>
> -Prachi
>
> On Tue, Sep 1, 2015 at 5:16 PM, Raul Kripalani wrote:
>
> > robots.txt is not functionally important in this context because we don't
> > have content we want to exclude from crawling.
> >
> > But it's always wise to serve at least a generic one because you don't know
> > if Google penalises sites that return an HTTP 404 for this file in terms of
> > SEO. I wouldn't be surprised if it did. And it's a simple file to add.
> >
> > Moreover, I would suggest creating a google-site-verification with a
> > sitemap controlled by us (if it hasn't been done yet - I'm on mobile now
> > and it's a pain to check). And also to hint the crawler to also crawl
> > readme.io and the javadoc. Currently if I google the term IgniteContext I
> > get the 1.1.0 javadoc page, which tells me that Google needs some hints to
> > crawl more recent javadocs better.
> >
> > Regards,
> > Raúl.
> > On 2 Sep 2015 00:36, "Dmitriy Setrakyan" wrote:
> >
> > > 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 <
> > > dsetrak...@apache.org
> > > > >
> > > > 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: website changes
I've created Google site verification for both, http and https version of
Ignite website. I've also added sitemap.xml and robots.txt.
If I may, I would like to suggest a server-side 301 redirect from http to
https version of the website to ensure that users and search engines are
directed to the preferred protocol (I'm guessing https pages are preferred
over http pages).
Thanks,
-Prachi
On Tue, Sep 1, 2015 at 5:16 PM, Raul Kripalani wrote:
> robots.txt is not functionally important in this context because we don't
> have content we want to exclude from crawling.
>
> But it's always wise to serve at least a generic one because you don't know
> if Google penalises sites that return an HTTP 404 for this file in terms of
> SEO. I wouldn't be surprised if it did. And it's a simple file to add.
>
> Moreover, I would suggest creating a google-site-verification with a
> sitemap controlled by us (if it hasn't been done yet - I'm on mobile now
> and it's a pain to check). And also to hint the crawler to also crawl
> readme.io and the javadoc. Currently if I google the term IgniteContext I
> get the 1.1.0 javadoc page, which tells me that Google needs some hints to
> crawl more recent javadocs better.
>
> Regards,
> Raúl.
> On 2 Sep 2015 00:36, "Dmitriy Setrakyan" wrote:
>
> > 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 <
> > dsetrak...@apache.org
> > > >
> > > 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: Added missing pages to Ignite documentation
Thanks Anton, I made a few edits. Please take a look and see if you agree. D. On Thu, Sep 10, 2015 at 3:08 AM, Anton Vinogradov wrote: > Done, thanks for tips > > On Thu, Sep 10, 2015 at 12:44 PM, Yakov Zhdanov > wrote: > > > I think that main docs should be in TopologyValidator interface. Other > > places should be briefly documented and contain a link to validator > > interface. > > > > Thanks! > > > > Yakov > > On Sep 10, 2015 11:22, "Anton Vinogradov" > > wrote: > > > > > Usage explaned at place where TopologyValidator used - at > > > CacheConfiguration.setTopologyValidator(tv). > > > Is it necessary to dublicate usage javadoc to TopologyValidator class? > > > > > > On Thu, Sep 10, 2015 at 11:00 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > wrote: > > > > > > > On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov < > > > > avinogra...@gridgain.com > > > > > wrote: > > > > > > > > > Dmitriy, > > > > > TopologyValidator's javadoc was improved as a part of these > changes. > > > > > > > > > > > > > I just checked in master, and this is the only javadoc I can find for > > > > TopologyValidator class: > > > > > > > > /** > > > > * Topology validator. > > > > */ > > > > > > > > A bit too pithy for my taste :) > > > > > > > > > > > > > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan < > > > > dsetrak...@apache.org> > > > > > wrote: > > > > > > > > > > > Thanks Anton! > > > > > > > > > > > > By the way, I just noticed that the TopologyValidator has no > > javadoc. > > > > > > Perhaps it makes sense to add it as well? > > > > > > > > > > > > D. > > > > > > > > > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > > > > > avinogra...@gridgain.com> > > > > > > wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I've created new pages on redme.io. > > > > > > > These pages describe usage of Ignite expiry policies and > topology > > > > > > > validator. > > > > > > > Urls: > > > > > > > https://apacheignite.readme.io/docs/expiry-policies > > > > > > > https://apacheignite.readme.io/docs/topology-validation > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-1404) Any distributed cache operation should throw CacheServerNotFoundException if there are no server nodes
Valentin Kulichenko created IGNITE-1404:
---
Summary: Any distributed cache operation should throw
CacheServerNotFoundException if there are no server nodes
Key: IGNITE-1404
URL: https://issues.apache.org/jira/browse/IGNITE-1404
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
Currently the behavior is inconsistent. E.g., {{remove()}} method throws an
exception, but {{clear()}} does not. Need to check all distributed operations
and make them throw the exception when appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1403) forOldest() cluster group returns predicate that is not updated when topology changes
Valentin Kulichenko created IGNITE-1403:
---
Summary: forOldest() cluster group returns predicate that is not
updated when topology changes
Key: IGNITE-1403
URL: https://issues.apache.org/jira/browse/IGNITE-1403
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
{{AgeClusterGroup}} that implements {{forOldest()}} and {{forYoungest}} cluster
groups is dynamically updated when topology changes. But the predicate that can
be acquired from this group via {{predicate()}} method is static, which is
incorrect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1402) Logging uses root logger in some cases
Valentin Kulichenko created IGNITE-1402:
---
Summary: Logging uses root logger in some cases
Key: IGNITE-1402
URL: https://issues.apache.org/jira/browse/IGNITE-1402
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
Fix For: ignite-1.4
{{GridKernalContext.log()}} method returns root logger which should not be used
by any of Ignite classes. This can cause the following scenario:
# User configures logger with DEBUG level as default and INFO level for
{{org.apache.ignite}} package.
# Ignite class takes logger using {{GridKernalContext.log()}} and checks if
debug is enabled. It will get true regardless of the settings for Ignite
package.
There are places in code that uses {{GridKernalContext.log()}} method
incorrectly, so it should be removed. We should always use
{{GridKernalContext.log(Class cls)}} properly specifying the category.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1401) Introduce special local node discovery events
Andrey Kornev created IGNITE-1401: - Summary: Introduce special local node discovery events Key: IGNITE-1401 URL: https://issues.apache.org/jira/browse/IGNITE-1401 Project: Ignite Issue Type: Improvement Components: general Reporter: Andrey Kornev Priority: Minor Currently, Ignite doesn't record the EVT_NODE_JOINED event for the local node. In general, it might be useful to know when the local node has joined the cluster as well as when the local node has left the cluster (or has failed to join). I'd like to propose to introduce a couple of new Ignite events: EVT_LOCAL_NODE_JOINED and EVT_LOCAL_NODE_LEFT that will be generated by the Discovery Manager when it has successfully started and when it has disconnected correspondingly. Importantly, the events must be generated by the discovery worker thread (and only this thread!) so that the total ordering of all discovery events is preserved. Clearly, the EVT_LOCAL_NODE_LEFT event should be generated and delivered on the best-effort basis. EVT_LOCAL_NODE_FAILED may also be considered: it could be generated when the cluster coordinator has refused the node's attempt to join the cluster (for whatever reason). The introduction of local node-specific discovery events rather than reusing the existing ones would help keep the existing code backward compatible, and in general makes sense. It is possible to approximate this feature using just the existing API, but the code is complex, prone to race conditions and may require use of Ignite internal APIs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
vert.x integration
This question goes to Andrey Gura. Andrey, I remember you have been working on Vert.x integration and got stuck on one bug in Ignite that had to be fixed before hand. Was that bug fixed by now? Can you let us know how close we are in your opinion to completing this integration? D.
[jira] [Created] (IGNITE-1400) Race during concurrent node stop and cache creation
Alexey Goncharuk created IGNITE-1400: Summary: Race during concurrent node stop and cache creation Key: IGNITE-1400 URL: https://issues.apache.org/jira/browse/IGNITE-1400 Project: Ignite Issue Type: Bug Components: cache Affects Versions: ignite-1.4 Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk Fix For: ignite-1.4 When node attempts to create a cache and is being stopped, both processes hang. The hang happens because gateway is blocked and cache create future is not cancelled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Platforms will not be included into the nearest release.
Moreover, we had very similar flow and quit using it in favor of current process. Thanks! Yakov On Sep 10, 2015 13:30, "Sergi Vladykin" wrote: > I think current git process[1] is ok for now. The only rule that was broken > here > is not merging feature to master until it is complete and ready for > release. > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Git+Process > > Sergi > > 2015-09-10 12:16 GMT+03:00 Raul Kripalani : > > > I suggest we settle on Gitflow as a branching model. > > > > This would mean creating an extra branch 'develop' which would be > > equivalent to SNAPSHOT, while 'master' would point to the latest release > > from the highest release line, e.g. if we have released 2.0.0 but still > > maintaining a 1.5.x release line, master would point to 2.0.0 even if > 1.5.2 > > is more recent in time. > > > > 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 Thu, Sep 10, 2015 at 9:03 AM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > > I agree. Going forward I think the master branch should only have > > > production-ready code. If something is not ready, there is no need to > > rush > > > with merges to master - keep it in your own branch. > > > > > > On Thu, Sep 10, 2015 at 12:56 AM, Vladimir Ozerov < > voze...@gridgain.com> > > > wrote: > > > > > > > Igniters, > > > > > > > > It seems I was too optimistic about adding platforms into the nearest > > > > release. While their are mostly ready for now, the keyword here is > > > > "mostly". We still need to think about documentation, build layout, > > > addinig > > > > Windows agents to TeamCity, and so on. > > > > > > > > I reverted changes which could be visible to users back and returned > > > > ignite-1.4 branch. Platforms will be released in the 1.5 release. > > > > > > > > Vladimir. > > > > > > > > > >
Re: [DISCUSS] PMC Chair rotation
On Thu, Sep 10, 2015 at 01:13PM, Sergi Vladykin wrote: > I believe Chair doesn't need our approval to start such a discussion :) > Probably we should set Chair reelection date to make this work? No one needs any approvals to start something around here, clearly ;) The point of this is to formalize the lazy fall-back instead of a hard action items. The keyword here is 'lazy' because this thing doesn't set a hard-date for the "reelection" nor oblige anyone to even make the reelection happen. I think this is one of those best engineering practices - "don't touch things if they work". So if the current Chair "works" well - we don't need to touch it just because we had set the reelection date. And as any good practice - it is quite daoistic. Cos > 2015-09-10 2:39 GMT+03:00 Roman Shaposhnik : > > > Obviously I'm a big +1 on that proposal since I have seen it work > > very well. > > > > Thanks, > > Roman. > > > > On Tue, Sep 8, 2015 at 9:01 PM, Konstantin Boudnik wrote: > > > Guys, > > > > > > I want to drop it on the list and see what are the thoughts the PMC. I > > think > > > it would be very beneficial for the members of this community if we > > institute > > > a policy to have regular rotations of the Chair. We do this in Bigtop > > and it > > > works real well for a couple of reasons: > > > - it provides an opportunity to anyone in the PMC to try this hat on > > and get > > >more involved in the inner-workings of the ASF and see how the board > > operates > > > - it guarantees that once you're a chair you aren't stuck holding the > > bag > > >forever and can pass it on if your time allocation changes > > > - such a policy makes the PMC very transparent > > > > > > And of course it doesn't mean that a new person _has_ to be the chair > > each > > > cycle. The same chair should remain if no one is nominated or gets the > > > majority of the votes. > > > > > > At Bigtop we passed a resolution to oblige the active chair to start the > > > [DISCUSS] thread at the end of his annual tenure and ask for > > nominations. The > > > active chair remains and no [VOTE] is needed if no nominations are made. > > > Pretty lazy and simple. > > > > > > If people aren't familiar with what's the PMC Chair and why all that > > fuzz, > > > please read on > > > https://www.apache.org/dev/pmc.html#chair > > > And I recommend everyone to take a look above PMC guide if you never > > seen it > > > before. > > > > > > Thoughts? > > > Cos > >
[jira] [Created] (IGNITE-1399) Exclude Ignite platform module
Sergey Kozlov created IGNITE-1399: - Summary: Exclude Ignite platform module Key: IGNITE-1399 URL: https://issues.apache.org/jira/browse/IGNITE-1399 Project: Ignite Issue Type: Bug Components: build Affects Versions: ignite-1.4 Reporter: Sergey Kozlov Priority: Critical Fix For: ignite-1.4 Ignite platform module isn't ready for release and should be excluded for build -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: SqlQuery.pageSize is ignored in replicated cache
Something like this could happen because replicated cache is incorrectly expected to have the whole dataset locally. I will take a look . Sergi 2015-09-10 15:38 GMT+03:00 Denis Magda : > Hi Sergi, > > I was fixing one of the many SQL query tests ( > https://issues.apache.org/jira/browse/IGNITE-613) when found that there > is an issue in how 'pageSize' parameter is processed by Ignite SQL engine. > > Test does the following. > > At the beginning it starts 3 server nodes and 1 client node. Fills a > replicated cache with 1000 entries. > > Right after that the following query is executed from the client node > > QueryCursor> q = > cache.query(new SqlQuery(Integer.class,"_key >= 0 > order by _key").setPageSize(10)); > > Then the test gets the first key in order to pre-load the first page: > > q.iterator().next().getKey() > > > However, the iterator loads all 1000 entries ignoring the page size that > is equal to 10. > I see that the iterator already holds all the entries in a list and > GridMapQueryExecutor.qryRess map on servers side is empty meaning that the > whole data was transferred to the client. > > Is this a bug or expected behavior? > > -- > Denis >
SqlQuery.pageSize is ignored in replicated cache
Hi Sergi, I was fixing one of the many SQL query tests (https://issues.apache.org/jira/browse/IGNITE-613) when found that there is an issue in how 'pageSize' parameter is processed by Ignite SQL engine. Test does the following. At the beginning it starts 3 server nodes and 1 client node. Fills a replicated cache with 1000 entries. Right after that the following query is executed from the client node QueryCursor> q = cache.query(new SqlQuery(Integer.class,"_key >= 0 order by _key").setPageSize(10)); Then the test gets the first key in order to pre-load the first page: q.iterator().next().getKey() However, the iterator loads all 1000 entries ignoring the page size that is equal to 10. I see that the iterator already holds all the entries in a list and GridMapQueryExecutor.qryRess map on servers side is empty meaning that the whole data was transferred to the client. Is this a bug or expected behavior? -- Denis
[jira] [Created] (IGNITE-1398) Platform .Net configuration should not be marshalled as portable type.
Vladimir Ozerov created IGNITE-1398: --- Summary: Platform .Net configuration should not be marshalled as portable type. Key: IGNITE-1398 URL: https://issues.apache.org/jira/browse/IGNITE-1398 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: ignite-1.5 We need to pass .Net configuration between Java and .Net platforms. However, this only needed for inter-process interaction. This object is never passed over a wire. We should remove its registration from portable marshaller and pass it by hand instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Platforms will not be included into the nearest release.
I think current git process[1] is ok for now. The only rule that was broken here is not merging feature to master until it is complete and ready for release. [1] https://cwiki.apache.org/confluence/display/IGNITE/Git+Process Sergi 2015-09-10 12:16 GMT+03:00 Raul Kripalani : > I suggest we settle on Gitflow as a branching model. > > This would mean creating an extra branch 'develop' which would be > equivalent to SNAPSHOT, while 'master' would point to the latest release > from the highest release line, e.g. if we have released 2.0.0 but still > maintaining a 1.5.x release line, master would point to 2.0.0 even if 1.5.2 > is more recent in time. > > 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 Thu, Sep 10, 2015 at 9:03 AM, Dmitriy Setrakyan > wrote: > > > I agree. Going forward I think the master branch should only have > > production-ready code. If something is not ready, there is no need to > rush > > with merges to master - keep it in your own branch. > > > > On Thu, Sep 10, 2015 at 12:56 AM, Vladimir Ozerov > > wrote: > > > > > Igniters, > > > > > > It seems I was too optimistic about adding platforms into the nearest > > > release. While their are mostly ready for now, the keyword here is > > > "mostly". We still need to think about documentation, build layout, > > addinig > > > Windows agents to TeamCity, and so on. > > > > > > I reverted changes which could be visible to users back and returned > > > ignite-1.4 branch. Platforms will be released in the 1.5 release. > > > > > > Vladimir. > > > > > >
Re: [DISCUSS] PMC Chair rotation
I believe Chair doesn't need our approval to start such a discussion :) Probably we should set Chair reelection date to make this work? Sergi 2015-09-10 2:39 GMT+03:00 Roman Shaposhnik : > Obviously I'm a big +1 on that proposal since I have seen it work > very well. > > Thanks, > Roman. > > On Tue, Sep 8, 2015 at 9:01 PM, Konstantin Boudnik wrote: > > Guys, > > > > I want to drop it on the list and see what are the thoughts the PMC. I > think > > it would be very beneficial for the members of this community if we > institute > > a policy to have regular rotations of the Chair. We do this in Bigtop > and it > > works real well for a couple of reasons: > > - it provides an opportunity to anyone in the PMC to try this hat on > and get > >more involved in the inner-workings of the ASF and see how the board > operates > > - it guarantees that once you're a chair you aren't stuck holding the > bag > >forever and can pass it on if your time allocation changes > > - such a policy makes the PMC very transparent > > > > And of course it doesn't mean that a new person _has_ to be the chair > each > > cycle. The same chair should remain if no one is nominated or gets the > > majority of the votes. > > > > At Bigtop we passed a resolution to oblige the active chair to start the > > [DISCUSS] thread at the end of his annual tenure and ask for > nominations. The > > active chair remains and no [VOTE] is needed if no nominations are made. > > Pretty lazy and simple. > > > > If people aren't familiar with what's the PMC Chair and why all that > fuzz, > > please read on > > https://www.apache.org/dev/pmc.html#chair > > And I recommend everyone to take a look above PMC guide if you never > seen it > > before. > > > > Thoughts? > > Cos >
Re: Added missing pages to Ignite documentation
Done, thanks for tips On Thu, Sep 10, 2015 at 12:44 PM, Yakov Zhdanov wrote: > I think that main docs should be in TopologyValidator interface. Other > places should be briefly documented and contain a link to validator > interface. > > Thanks! > > Yakov > On Sep 10, 2015 11:22, "Anton Vinogradov" > wrote: > > > Usage explaned at place where TopologyValidator used - at > > CacheConfiguration.setTopologyValidator(tv). > > Is it necessary to dublicate usage javadoc to TopologyValidator class? > > > > On Thu, Sep 10, 2015 at 11:00 AM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov < > > > avinogra...@gridgain.com > > > > wrote: > > > > > > > Dmitriy, > > > > TopologyValidator's javadoc was improved as a part of these changes. > > > > > > > > > > I just checked in master, and this is the only javadoc I can find for > > > TopologyValidator class: > > > > > > /** > > > * Topology validator. > > > */ > > > > > > A bit too pithy for my taste :) > > > > > > > > > > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > > wrote: > > > > > > > > > Thanks Anton! > > > > > > > > > > By the way, I just noticed that the TopologyValidator has no > javadoc. > > > > > Perhaps it makes sense to add it as well? > > > > > > > > > > D. > > > > > > > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > > > > avinogra...@gridgain.com> > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I've created new pages on redme.io. > > > > > > These pages describe usage of Ignite expiry policies and topology > > > > > > validator. > > > > > > Urls: > > > > > > https://apacheignite.readme.io/docs/expiry-policies > > > > > > https://apacheignite.readme.io/docs/topology-validation > > > > > > > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-1397) Load/consistency test framework
Artem Shutak created IGNITE-1397: Summary: Load/consistency test framework Key: IGNITE-1397 URL: https://issues.apache.org/jira/browse/IGNITE-1397 Project: Ignite Issue Type: Task Reporter: Artem Shutak Assignee: Artem Shutak Need to create "Load/consistency test framework". See: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61316109. As POC it should be implemented test cases described on the wiki. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Added missing pages to Ignite documentation
I think that main docs should be in TopologyValidator interface. Other places should be briefly documented and contain a link to validator interface. Thanks! Yakov On Sep 10, 2015 11:22, "Anton Vinogradov" wrote: > Usage explaned at place where TopologyValidator used - at > CacheConfiguration.setTopologyValidator(tv). > Is it necessary to dublicate usage javadoc to TopologyValidator class? > > On Thu, Sep 10, 2015 at 11:00 AM, Dmitriy Setrakyan > > wrote: > > > On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov < > > avinogra...@gridgain.com > > > wrote: > > > > > Dmitriy, > > > TopologyValidator's javadoc was improved as a part of these changes. > > > > > > > I just checked in master, and this is the only javadoc I can find for > > TopologyValidator class: > > > > /** > > * Topology validator. > > */ > > > > A bit too pithy for my taste :) > > > > > > > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > wrote: > > > > > > > Thanks Anton! > > > > > > > > By the way, I just noticed that the TopologyValidator has no javadoc. > > > > Perhaps it makes sense to add it as well? > > > > > > > > D. > > > > > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > > > avinogra...@gridgain.com> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I've created new pages on redme.io. > > > > > These pages describe usage of Ignite expiry policies and topology > > > > > validator. > > > > > Urls: > > > > > https://apacheignite.readme.io/docs/expiry-policies > > > > > https://apacheignite.readme.io/docs/topology-validation > > > > > > > > > > > > > > >
Re: Platforms will not be included into the nearest release.
I suggest we settle on Gitflow as a branching model. This would mean creating an extra branch 'develop' which would be equivalent to SNAPSHOT, while 'master' would point to the latest release from the highest release line, e.g. if we have released 2.0.0 but still maintaining a 1.5.x release line, master would point to 2.0.0 even if 1.5.2 is more recent in time. 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 Thu, Sep 10, 2015 at 9:03 AM, Dmitriy Setrakyan wrote: > I agree. Going forward I think the master branch should only have > production-ready code. If something is not ready, there is no need to rush > with merges to master - keep it in your own branch. > > On Thu, Sep 10, 2015 at 12:56 AM, Vladimir Ozerov > wrote: > > > Igniters, > > > > It seems I was too optimistic about adding platforms into the nearest > > release. While their are mostly ready for now, the keyword here is > > "mostly". We still need to think about documentation, build layout, > addinig > > Windows agents to TeamCity, and so on. > > > > I reverted changes which could be visible to users back and returned > > ignite-1.4 branch. Platforms will be released in the 1.5 release. > > > > Vladimir. > > >
Re: Added missing pages to Ignite documentation
Usage explaned at place where TopologyValidator used - at CacheConfiguration.setTopologyValidator(tv). Is it necessary to dublicate usage javadoc to TopologyValidator class? On Thu, Sep 10, 2015 at 11:00 AM, Dmitriy Setrakyan wrote: > On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov < > avinogra...@gridgain.com > > wrote: > > > Dmitriy, > > TopologyValidator's javadoc was improved as a part of these changes. > > > > I just checked in master, and this is the only javadoc I can find for > TopologyValidator class: > > /** > * Topology validator. > */ > > A bit too pithy for my taste :) > > > > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > > Thanks Anton! > > > > > > By the way, I just noticed that the TopologyValidator has no javadoc. > > > Perhaps it makes sense to add it as well? > > > > > > D. > > > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > > avinogra...@gridgain.com> > > > wrote: > > > > > > > Hello, > > > > > > > > I've created new pages on redme.io. > > > > These pages describe usage of Ignite expiry policies and topology > > > > validator. > > > > Urls: > > > > https://apacheignite.readme.io/docs/expiry-policies > > > > https://apacheignite.readme.io/docs/topology-validation > > > > > > > > > >
Re: Platforms will not be included into the nearest release.
I agree. Going forward I think the master branch should only have production-ready code. If something is not ready, there is no need to rush with merges to master - keep it in your own branch. On Thu, Sep 10, 2015 at 12:56 AM, Vladimir Ozerov wrote: > Igniters, > > It seems I was too optimistic about adding platforms into the nearest > release. While their are mostly ready for now, the keyword here is > "mostly". We still need to think about documentation, build layout, addinig > Windows agents to TeamCity, and so on. > > I reverted changes which could be visible to users back and returned > ignite-1.4 branch. Platforms will be released in the 1.5 release. > > Vladimir. >
Re: Added missing pages to Ignite documentation
On Thu, Sep 10, 2015 at 12:35 AM, Anton Vinogradov wrote: > Dmitriy, > TopologyValidator's javadoc was improved as a part of these changes. > I just checked in master, and this is the only javadoc I can find for TopologyValidator class: /** * Topology validator. */ A bit too pithy for my taste :) > On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan > wrote: > > > Thanks Anton! > > > > By the way, I just noticed that the TopologyValidator has no javadoc. > > Perhaps it makes sense to add it as well? > > > > D. > > > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > > avinogra...@gridgain.com> > > wrote: > > > > > Hello, > > > > > > I've created new pages on redme.io. > > > These pages describe usage of Ignite expiry policies and topology > > > validator. > > > Urls: > > > https://apacheignite.readme.io/docs/expiry-policies > > > https://apacheignite.readme.io/docs/topology-validation > > > > > >
Platforms will not be included into the nearest release.
Igniters, It seems I was too optimistic about adding platforms into the nearest release. While their are mostly ready for now, the keyword here is "mostly". We still need to think about documentation, build layout, addinig Windows agents to TeamCity, and so on. I reverted changes which could be visible to users back and returned ignite-1.4 branch. Platforms will be released in the 1.5 release. Vladimir.
Re: Added missing pages to Ignite documentation
Dmitriy, TopologyValidator's javadoc was improved as a part of these changes. On Thu, Sep 10, 2015 at 6:41 AM, Dmitriy Setrakyan wrote: > Thanks Anton! > > By the way, I just noticed that the TopologyValidator has no javadoc. > Perhaps it makes sense to add it as well? > > D. > > On Sat, Sep 5, 2015 at 11:15 PM, Anton Vinogradov < > avinogra...@gridgain.com> > wrote: > > > Hello, > > > > I've created new pages on redme.io. > > These pages describe usage of Ignite expiry policies and topology > > validator. > > Urls: > > https://apacheignite.readme.io/docs/expiry-policies > > https://apacheignite.readme.io/docs/topology-validation > > >
[jira] [Created] (IGNITE-1396) Remove platforms from public API for ignite-1.4.
Vladimir Ozerov created IGNITE-1396: --- Summary: Remove platforms from public API for ignite-1.4. Key: IGNITE-1396 URL: https://issues.apache.org/jira/browse/IGNITE-1396 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Priority: Critical Fix For: ignite-1.4 It appears that adding platforms in the current release will shift release date without real necessity. Lets hide platforms API from release for now and re-add it in 1.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
