John, For case 1: That logic to contact dead members needs to stay: If you look at commit c4cb0d7c6c7066b84c161fd4de7a35e029367310 "periodically attempt to contact dead members". There is a condition where nodes the dead nodes would not revive so attempting to gossip to known dead nodes helps.
For case 2: Yes. You can search the dev list for discussions on this.This is definitely a direction we want to go in. We did half the changes here https://issues.apache.org/jira/browse/GOSSIP-2. HTTP is a natural place for Gossip to go, since just about everything is a web service these days. For case 3: No. the concept is that different clusters should never talk to each other. It is a check in place so that two networks that happen to talk to each other accidentally do not converge on each other. Thanks, Edward On Fri, Nov 4, 2016 at 1:30 PM, John Naylor <[email protected]> wrote: > Edward, > > Thanks for the quick response. I am very new to gossip, but have it > behaving the way I want it to work, so if I may throw a few questions out > at the start it would help me to see if I am going in the wrong direction > or have missed something > > 1. ActiveGossipThread.init() schedules a number of commands. One of those > commands is to send off the List of dead members, but since the random > partner node to send to is pulled from that List, there is probably a good > chance that node will be dead. I eliminated that command, preferring to let > dead nodes come about on each node based on the timeout. Am I missing > something here? > > 2. It may not make sense in the gossip world, but I want to send messages > via https. It was my guess that the Transport interface was intended to be > used so that different Transport implementations could be dropped into > place. I added a sendMessage method to the interface, and created > implementations for UDP, HTTP, HTTPS, and Thread(allows simple gossip > testing in a single JVM). Is this a reasonable direction for gossip or is > UDP the only accepted transport? > > 3. GossipCore.receive() will not add a member if it comes from a different > cluster. Would it be reasonable to make that configurable so that filtering > could be ignored if desired? > > There are a few more things on my list but I will leave it at that for now. > > Thanks, > John Naylor > > > > > > On Nov 4, 2016, at 12:21 PM, Edward Capriolo <[email protected]> > wrote: > > > > John, > > > > Very very cool stuff. If you can share please let everyone know the use > > case! > > > > If the bug/feature is small or obvious the process is this: > > > > 1) File a jira issue: > > https://issues.apache.org/jira/browse/GOSSIP/?selectedTab=com.atlassian. > jira.jira-projects-plugin:summary-panel > > 2) Briefly discuss the problem/feature. Jira will give you a issue number > > like GOSSIP-99 > > 3) Create a fork of https://github.com/apache/incubator-gossip and name > > your branch GOSSIP-99 > > 4) Create the fix/feature and issue a Pull Request > > 4.1) squash commits, add tests make the PR as clean as possible > > 5) We review and merge > > > > If you feel the change is complex and warrants larger up front discussion > > you can describe the feature/bug here. We can discuss the broad strokes > and > > decide as a group what the next steps are. > > > > It is important to note that we are a small group currently and would > enjoy > > any conversation on list as well. > > > > Thanks, > > Edward > > > > > > > > On Fri, Nov 4, 2016 at 11:46 AM, John Naylor <[email protected]> > wrote: > > > >> Good morning, > >> > >> I’ve never worked on an open source project before, but I’ve been using > >> gossip for a project here at work. I have made some changes and wanted > to > >> submit those back to the project, just not sure of the process. > >> > >> Thanks, > >> John Naylor > >
