[jgroups-dev] what happened to treeMESH?

I know it has been a long time since I have been active on here.  Sadly 
I have not been able to work on treeMESH in a little over a month now.  
Work got very busy with other things that were unrelated to this project.

Sadly, in the last 2 weeks there has been discussions about other 
possible solutions to our scalability problems.  Primarily with the idea 
that we could have sub groups/clusters, with the idea that then we could 
have smaller clusters of servers, and transfer only relevant information 
within these groups.  Without going too much into detail, it seems like 
work on the treeMesh has haulted from my companies perspective (at least 
for the time being).  It had nothing to do with any actual deficiencies 
in my treeMesh design, just questioning if a simpler solution might work 
just as good (treeMESH is definitely not the simplest solution, I just 
feel the most robust).

I wanted to go ahead and present you guys with the work I have done.  It 
may not be useful to anyone, and it may never get used.  But from my 
perspective this is a really good idea, that just has not been fully 
fledged out.  I hope that someone can at least be inspired by some of 
the ideas I have been working on (lack of guarantees in order to favor 
performance and a distributed framework).

With that said, I went ahead and fixed one of the last major known 
issues with the treeMesh.  I know that further issues exist around 
failures that are in relation to the root node (for example, if a node 
connected to a root node fails, then the root node will try to merge and 
cause a cycle of peer connections...this results in a less than optimal 
graph structure).  I think that these issues may be solved by having a 
concept that once you were the tree's root, you will always be the 
tree's root (unless the root itself fails).  I think that this could be 
a drop in fix for that issue, but I have not spent the time to verify 
that it will work with every angle.  If anyone is interested in this 
project, I will go ahead and spend the time to find a solution to this 
problem.  But I also suspect that lots more issues exist.  Sadly my 
work's QA never got to even look at this implementation, so the only 
testing that has occurred has been from me doing my best to break it. 

In addition, if you look in the code you will see it has lots of points 
where it is incomplete.  Lots of TODO statements about things I think 
need investigated further, TODO statements about temporary stuff just to 
make sure everything is running safe, etc.

I have updated the design document to reflect the most recent ideas that 
the treeMESH is designed on.  You can view it here:
http://archive.jentfoo.com/coding_projects/treeMesh/jentMesh_design-v0.2.pdf

You can download a tar ball which contains any files I modified for the 
treeMESH here (including the protocol itself):
http://archive.jentfoo.com/coding_projects/treeMesh/treeMesh-V0.2.tar.gz

By default the treeMESH node will write to a file with a name like: 
<randomNumber>_status.txt
These files are used by a third tool I call the "meshGUI" which draw the 
connections between nodes on a graph.  This allows you to visualize what 
the graph structure actually looks like.  You can download this tool here:
http://archive.jentfoo.com/coding_projects/treeMesh/meshGUI.jar

It is then used like this:
java -jar meshGUI.jar path/to/status.txt
OR
java -jar meshGUI.jar "path/to/status.txt" #by passing the argument in 
as a string, the meshGUI will scan that folder for updates, that way you 
can use a wild card, ie "mount/node*/*_status.txt" and it will notice 
when new nodes join...if you do it without making it a string, then bash 
will auto fill the wildcards, and you will need to restart the gui every 
time you start a new node

Description of the protocols included:
TREEFD - failure detection and merging for the treeMesh (should be used)
TREEMESH - basic tree mesh protocol, has many configurable options...I 
suggest you read through them...it was designed to be somewhat 
configurable between performance and safety/needs (for example there is 
a much better routing protocol, but it comes at a slight performance hit)
VisibleTREEMESH - extends TREEMESH, this binds to port 28241, allowing 
you to send commands to the node.  This was primarily built so that QA 
could help get insight into what is going on in the node.  The commands 
should be expanded, but it allows you to do actions that the treeMESH 
would not have taken on it's own (for example you can have one node 
blacklist communications to another node, to simulate a failure for two 
nodes to communicate, and ensure that data is routed around the failed 
connection).  It also lets you query for state (although the same state 
can be read with some difficulty from within the logs).  One of the most 
useful features is being able to adjust logging levels without rebooting 
the node.

I have other tools as well, but have not packaged them for 
distribution.  If you have any interest in these, let me know.  These 
tools are pretty full featured and work great, I have no objection to 
sharing them.  I just was not sure if there was enough interest in all 
these things to package them for download.  But on request I 
can....Those other tools/programs include:
* performance tester, where it tests the speeds that it can communicate 
with different nodes, this involves message routing and other mechanisms 
that the treeMesh is not necessarily designed for, but still performs 
decently with
* chat program that can show mesh structure
* IRC bridge for the chat program, so that you can have nodes running on 
treeMesh and interface with an IRC channel just like they were normal 
IRC users
* different versions of meshGUI (but the best one is included for download)
* examples of how application code can use treeMesh to its advantage for 
an epidermicly replicated data structure

This was a really fun project.  I am somewhat sad to see it probably 
end.  I still see lots of potential in it, and lots of great ideas from 
it.  As you can probably tell from my writing, I have a decent idea of 
what problems remain, and ideas about how to tackle those issues.  The 
only reason I am posting a partially completed design is that since my 
work is less likely to use it, I only want to continue working on it if 
others can find uses and interest in it.  I love coding interesting 
projects and such, but unless it actually gets used, it feels sorta 
empty.  I would be very willing to continue this project, continue to 
support, continue to develop and fix.  But interest for it has to be 
there.  So feel free to ping me on questions about the 
use/implementation/design/whatever.  I will be MORE than happy to answer 
and talk about this very interesting project.

Thanks for all your guys help in understanding JGroups, and looking at 
the very minor bugs/issues I came across.  I hope to be able to continue 
work with the JGroups developers in the future.

Cheers,
Mike Jensen
http://www.spicylemons.com


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Javagroups-development mailing list