S3 discovery and docker bridge networks

The general problem is a when a node pushes its IP addresses to S3, it has no way to tell whether one of its IP address will be usable by other nodes. On the consumer side, we are unable to determine at runtime which of the addresses will work. So we end up doing discovery using worthless IP

[jira] [Created] (IGNITE-10791) Avoid unusable network during discovery

David Harvey created IGNITE-10791: - Summary: Avoid unusable network during discovery Key: IGNITE-10791 URL: https://issues.apache.org/jira/browse/IGNITE-10791 Project: Ignite Issue Type

Re: TcpCommunicationSpi extension to ignore docker bridge network

rejected, unless Ignite has explicit code to do detected and ignore a self message. But if there is a IP:port pair that the current node is claiming as an endpoint, it should not try to use that IP:port to connect to other nodes. On Tue, Nov 20, 2018 at 2:27 PM David Harvey wrote: > What

Re: TcpCommunicationSpi extension to ignore docker bridge network

I this we can add this to > the Ignite so that it works out of the box. > > --AG > > > вт, 20 нояб. 2018 г. в 19:58, David Harvey : > > > We see some annoying behavior with S3 discovery because Ignite will push > to > > the discovery S3 bucket the IP address of t

TcpCommunicationSpi extension to ignore docker bridge network

We see some annoying behavior with S3 discovery because Ignite will push to the discovery S3 bucket the IP address of the local docker bridge network (172.17.0.1) in our case. Basically, each node when coming online tries that address first, and has to go through a network timeout to recover.

[jira] [Created] (IGNITE-10135) Documentation link to ClusterNodeAttributeAffinityBackupFilter

David Harvey created IGNITE-10135: - Summary: Documentation link to ClusterNodeAttributeAffinityBackupFilter Key: IGNITE-10135 URL: https://issues.apache.org/jira/browse/IGNITE-10135 Project: Ignite

Re: IGNITE-2.7. New Features

IGNITE-9365 Force backups to different AWS availability zones using only Spring XML This deserves documentation enhancements: https://apacheignite.readme.io/docs/affinity-collocation What is the mechanism for proposing an update for 2.7? On Fri, Nov 2, 2018 at 6:31 AM Andrey Kuznetsov wrote:

Re: Pre-touch for Ignite off-heap memory

Denis, We run must of our production DBs systems without any swapping space, because the 10-100x drop in throughput if such systems start paging makes them worse than useless. However, we don't get OOM on them until all the pages are dirty, since LINUX will page out read-only (code) pages or

Re: Applicability of term 'cache' to Apache Ignite

We had a terminology agreement early on where we agreed to call them caches, but we still call them tables anyway. When I finally understood how you could have multiple tables in a single cache, I tried to find example use cases, but couldn't. Is there even a test with multiple queryEntities?

Need Review IGNITE-7616 Mxbeans thread display.

1. This is my second newbie submission, it could use a review, and I keep getting snapshot dependency errors in teamcity that seem like the cannot be related to my changes, even after rebasing 2 twice. I couldn't find a crisp defintion of what a snapshot dependency is.

Re: affinityBackupFilter for AWS Availability Zones

Yes, thanks Val! On Mon, Sep 24, 2018 at 11:35 AM Dmitriy Pavlov wrote: > Hi Val, many thanks for the review. > > ср, 12 сент. 2018 г. в 20:35, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Yes, will try to review this week. > > > > -Val > > > > On Wed, Sep 12, 2018 at 10:24 AM

First pull requests

I'm new to this process, and I've created three pull requests, and I'm trying to figure out how I can get some eyes to look at them. - IGNITE-7616 which add some missing MXbeans for thread pools. I've identified some contributors that

Re: Critical worker threads liveness checking drawbacks

itical thread should monitor each other? For > instance, if all the tasks were blocked and unable to run, > node reset would never occur. As for me, a better solution is to use a > separate monitor thread or pool (maybe both with software > and hardware checks) that not only checks h

Re: Critical worker threads liveness checking drawbacks

It would be safer to restart the entire cluster than to remove the last node for a cache that should be redundant. On Sun, Sep 9, 2018, 4:00 PM Andrey Gura wrote: > Hi, > > I agree with Yakov that we can provide some option that manage worker > liveness checker behavior in case of observing

Re: Critical worker threads liveness checking drawbacks

There are at least two production cases that need to be distinguished: The first is where a single node restart will repair the problem( and you get the right node. ) The other cases are those where stopping the node will invalidate it's backups, leaving only one copy of the data, and the problem

Minor version changes and server/client compatibility

We have needed to do a couple of simple bug fixes to ignite proper, where there is no change to interfaces or internode communications. When we do this, we end up with these choices: - Coordinate client and server code bases so that they are in lock step. Tedious with multiple clusters

Re: GridClosureProcessor.affinityRun() semantics

hen I think it's a bug - I would throw an exception in this case. However, > is there any particular reason you're doing this? Is there a use case? I > don't see much sense in combining affinityRun with a cluster group. > > Backup no node is never used by affinityRun to my knowledge.

GridClosureProcessor.affinityRun() semantics

This function takes: int partId, ... @Nullable Collection nodes, It uses partId to find the node with the primary partition, and proceeds even if that node is not in the subgrid that was passed in. This is either a bug, or the semantics should be specified more

Re: affinityBackupFilter for AWS Availability Zones

this > page: https://apacheignite.readme.io/docs/docker-deployment > > But anyway, I believe that such contribution might be very valuable for > Ignite. Feel free to create a ticket. > > -Val > > On Thu, Aug 23, 2018 at 11:58 AM David Harvey > wrote: > > > I need an affin

[jira] [Created] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML

David Harvey created IGNITE-9365: Summary: Force backups to different AWS availability zones using only Spring XML Key: IGNITE-9365 URL: https://issues.apache.org/jira/browse/IGNITE-9365 Project

affinityBackupFilter for AWS Availability Zones

I need an affinityBackupFilter that will prevent backups from running in the same AWS availability zone. (A single availability zone has the characteristic that some or all of the EC2 instances in that zone can fail together due to a single fault. You have no control over the hosts on which the

New Contributor - IGNITE-7616

I've be working with ignite for almost a year, but haven't contributed anything back yet. IGNITE-7616 is annoying me, so I might as well just fix it. My Jira ID is syssoftsol. Thanks, -DH

[jira] [Created] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode

David Harvey created IGNITE-9026: Summary: Two levels of Peer class loading fails in CONTINUOUS mode Key: IGNITE-9026 URL: https://issues.apache.org/jira/browse/IGNITE-9026 Project: Ignite

[jira] [Created] (IGNITE-7905) Setting userVersion in ignite.xml causes ignite.active(true) to fail

David Harvey created IGNITE-7905: Summary: Setting userVersion in ignite.xml causes ignite.active(true) to fail Key: IGNITE-7905 URL: https://issues.apache.org/jira/browse/IGNITE-7905 Project: Ignite

[jira] [Created] (IGNITE-6344) AWS AMI startup.sh gets spurious error on export statment

David Harvey created IGNITE-6344: Summary: AWS AMI startup.sh gets spurious error on export statment Key: IGNITE-6344 URL: https://issues.apache.org/jira/browse/IGNITE-6344 Project: Ignite