On 17/12/2012 21:08, Greg Turnquist wrote: > I ran into issues using McastService on my own setup. Took me awhile to > figure out I was colliding with another instance of tomcat running > elsewhere, sharing the same multicast port. I have started thinking that if > I wrote a different version of McastService that embedded some sort of > logical cluster name, I could detect collisions with other, > differently-named clusters and write some log messages to cause things to > fail faster. In the process, I found that code like > org.apache.catalina.tribes.membership.MessageImpl is highly cohesive. There > are a lot of hard-coded downcasts to the concrete implementation instead of > relying on interfaces. > > I was planning to work on a potential patch to submit here that would > involve refactoring things so there are no down casts to MessageImpl and > also possibly removing the static calls as well. With that, it should > become easier to code alternative protocols, including my own that I need > (and hope to contribute back), as well as supporting others that want to > design a pluggable message protocol between their own instances. > > If anyone has an opinion on this, please let me know. I'll update this list > when I have a patch to consider.
Any changes to Tomcat that make it easier (or possible) to plug-in custom implementations are welcome. I agree that interfaces should be used and that they are not always used. I support any efforts to improve this. I recommend starting with a small patch to ensure you are heading in an acceptable direction. It would be frustrating to spend a fair amount of time on a large patch only to see it rejected for some reason. Several small steps are generally better than one big one. A new McastService is not the only way to solve the problem you encountered. As of 7.0.31 the current cluster membership via JMX and I can think of a couple of further changes that could help debug both the particular problem you encountered as well as other clustering issues. 1. Add the current cluster membership to the manager status page. 2. Add logging that lists the current cluster membership when a node joins a cluster. That way, from the logs of any node, you'll have a full list of current cluster members. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
